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
Jose
|