Integration: MIT Kerberos V and OpenLDAP with SASL/GSSAPI

[Kevin <openldap@gnosys.biz>]

Hi All-

I'm trying to integrate the subject software and having difficulty 
with the part that seems most mysterious to me:
getting slapd to say, "Oh, a user is trying to do initial kerberos 
authentication through me...
I need to accept the offered authentication credentials
temporarily, then take them to the KDC and ask the KDC if they are
satisfactory or not, and then if they are, get the tickets from the
KDC and pass them back to the user's ticket cache, including the
krbtgt and perhaps the ldap service principal."  In other words,
establishing the connection between LDAP and the KDC.  This is what seems
quite mysterious to me.  At first I thought that the {KERBEROS} in the
userPassword attribute along with the user's kerberos principal was the
key, but when I examine my KDC logs, I'm not even showing that anyone
(slapd or anything else) is asking for a TGT for the user, so now I'm
not too sure about that.

I can do a kinit user and get a krbtgt with no problems.  Once I've
done that as a normal user, I can query the Directory
as that user and get my query answered, and in the process of course,
obtain the ldap service principal.  This works fine.  If I try it after
kdestroy, then it fails which is what I would expect: the ldap server
refuses to answer queries from unauthenticated users (and this is what
I think I've coded in my ACLs).

But when I attempt to authenticate, LDAP asks me for my LDAP password (which
should be carried back to the KDC), but fails to authenticate me, in spite of
being given the correct password.  I would expect that my KDC logs would
show an attempted query for a TGT here, but they don't, and LDAP says:
Enter LDAP Password:
ldap_bind: Invalid credentials (49)

I've studied Turbo's HOWTO and ACL file.  In it, he reports that he spent
4 or 5 days trying to get this functionality working, and that he was
certain that the resolution revolved around coding the ACLs correctly.

Problem is, though, I can't make out what he's trying to say when he
writes this as an ACL:

===============================================================
# Since we're using {KERBEROS}<PRINCIPAL>, we can't allow the user
# to change the password. They have to use the Kerberos 'kpasswd' to
# do this... But the admin can change (if need be).
# Please see krb5 userPassword attribute
access to attr=userPassword
        by dn="cn=admin,ou=People,dc=papadoc,dc=bayour,dc=com" write
        by dn="uid=ldapadm.+\+realm=<YOUR KERBEROS REALM>" write
        by anonymous auth
        by * none
===============================================================

It looks to me like the first "by" line is to permit the rootdn
("admin"... ldap administrator) to write, and it looks like the second "by"
line is doing the same thing ("ldapadm"?).  I guess I don't understand
the escape sequence (if that's what it is) either: +\+.  He says ordering of
ACLs is important, but...  Why does he seem to have two "by" lines that
do the same thing?

My corresponding ACL looks like this:
===============================================================
access to attr=userPassword
        by dn="uid=ldapadmin,cn=PLAINJOE.ORG,cn=gssapi,cn=auth" write
        by anonymous auth
        by * none
===============================================================

and I have these other settings in my slapd.conf file:

===============================================================
sasl-realm      PLAINJOE.ORG
database        bdb
suffix          "dc=plainjoe,dc=org"
rootdn          "uid=ldapadmin,cn=PLAINJOE.ORG,cn=gssapi,cn=auth"
===============================================================

and this all works (other than what I described above).

I learned the hard way that if I explicitly set the REALM with sasl-realm as
I've done here, then I must also have it in the rootdn as a cn=PLAINJOE.ORG.
If I don't explicitly set sasl-realm, then I don't need the cn=PLAINJOE.ORG
in my rootdn, and some check of the default realm in /etc/krb5.conf is
probably done.

For any of you that might already be doing this, how do you establish
the connection between LDAP and the authentication server?


-Kevin