[Date Prev][Date Next] [Chronological] [Thread] [Top]

LDAPv3: The OpenLDAP/Kerberos/SASL soup (was Kerberos and DIGEST-MD5)

    Ok, I think I have done my homework reading a lot of past posts in the mailing list, and this is what I have found... I hope this helps to anyone interested in this. In addition I would like to hear your comments about some of the points:
  • There is something called LDAPv3 that may be achieved to some extent combining LDAP, Kerberos and SASL. This gives us a central authentication server with single sign on capabilities, secure authentication against the directory server (and other kerberized servers with the help of SASL/GSSAPI), central respository of user/entities information and with a bit of luck will wash your dishes in the absence of your girl friend/spouse (I must double check this last item)
  • Regarding Kerberos, Heimdal is preferred against MIT due basically to the ability of Heimdal to store its KDC database in LDAP and to some annoying threading issues with MIT. Heimdal uses krb5-kdc.schema for the schema definition, krb5KDCEntry as the objectclass for KDC entries, and stores the password in the encrypted attribute krb5Key (is this correct?). I have a doubt here... krb5KDCEntry is an auxiliary class, so either Heimdal uses an structural class (which one?) in addition to krb5KDCEntry when creating an entry or OpenLDAP will complain about this...
  • Taking into accout the last point I assume a sensible implementation of a Heimdal/OpenLDAP directory would combine common attributes (inetOrgPerson) and security attributes (krb5KDCEntry) in the same directory object under ou=people,dc=whatever,dc=com... am I right?
  • If everything is correctly configured (this also involves tweaking pam and nss) you will be able to get a Kerberos ticket after your login, and then you will be able to access OpenLDAP through SASL/GSSAPI without having to enter again your user and password... we have single sign on!!!! (I don't know if I prefer this or the dish washing functionality... aren't they lovely? ;o) )
  • Let's talk now about non kerberized applications (by the way, is this a verb? :o) ). If you want to provide simple bind functionality you have to store some kind of password in the userPassword field. Here you have several options:
    • Use {KERBEROS}user@REALM. This is deprecated, as it seems the code is unmantained and being phased out. Any way you still may access this using an environment variable while compiling.
    • Use {SASL}user@REALM. You must compile OpenLDAP with --enable-spasswd for this to work. This makes use of the SASL authentication mechanisms to check the provided password against the backend of choice. It is not recommended to use Kerberos for this, as this makes the whole operation quite inefficient, and would slow down the machine in heavy load scenarios (basically you have a lot of unused tickets floating around). Anyway a lot of people uses this because of the convenience of having only one password database.
    • Use a real password (it must be in clear text if you want to provide DIGEST-MD5), that should be synchronized with the Kerberos password. There doesn't seem to be a simple way of doing this... maybe this could be achieved either with a tricky combination of ACLs, pam configuration, and duplicated initialization of entries, or with the smbk5pwd module, available in CVS, that does one way synchronization from userPassword to krb5Key.
    • Use {KRB5KEY} (????). I have found some mails that mention something about setting an encrypted password using {KRB5KEY}, but I haven't been able to find more information about this... must Heimdal be configured to set userPassword to this? Is this information taken/copied from krb5Key?
    • Of course, make use of TLS/SSL if you are planning to provide simple bind authentication. You don't want to blow out your whole Kerberos security having those passwords floating around your network, do you?
  • About DIGEST-MD5... it seems this is a mandatory SASL mechanism to offer if you want to have a shining LDAPv3 compliant service... *but* (I hate this word) you need to have clear text password (a shared secret) stored somewhere. This may be OpenLDAP, or the sasldb2 database (in case you are using Cyrus SASL... I don't know of any other open source implementation of SASL anyway). For comments on having this stored in LDAP, see previous point... a bit tricky. In case you store them in the sasldb2 database, you will have to mantain duplicated entries in Kerberos/LDAP and sasldb2. Anyway, OpenLDAP doesn't completely implement the whole LDAPv3 standard, so maybe we won't miss DIGEST-MD5 that much until there is an easier way of doing it...
    I hope this helps to anyone trying to setup a Kerberos/OpenLDAP/SASL server.

    TIA, best regards