I’ve been going through quite a few OpenLDAP configuration steps already, but there are still new setup possibilities to try. I’m not sure if I’m always too curious or if it’s just the new Ubuntu Lucid that is making me try how these things are working with it.
Now that MIT Kerberos is running using OpenLDAP as storage backend, the next logical step is to make OpenLDAP use MIT Kerberos as its password backend. If one needs both kerberos ja ldap bind authentication working, it’s really easy to get some of those passwords out of sync. Users are usually not happy if they suddenly start having randomly different passwords for different services when they change their password. Until now I’ve been using tools that always update the different passwords (userPassword in ldap, ntml hash for samba and kerberos) at the same time, but sometimes there have been problems making sure that all actually changed.
To make syncing possible, I’ll be going through the steps to get OpenLDAP to forward the ldap binds to SASL which in turn forwards them to Kerberos using GSSAPI. This solution works when there is need to support ldap binds for applications that don’t support kerberos directly. This shouldn’t be mistaken for real kerberos authentication as this solution still needs the user password to be sent to OpenLDAP over the wire.
The following documents tell more background information and were used to do the configuration described in this posting:
- Wikipedia on SASL
- RFC #4422 – Simple Authentication and Security Layer (SASL)
- OpenLDAP’s Pass-Through authentication
Simple Authentication and Security Layer (SASL) is one of the mysterious acronyms that pop up once in a while, but often one really cannot figure out what it does. SASL makes it possible to authenticate connection based protocols with any authentication method that the server and client both support. This means that the protocol itself does not need to define all the authentication methods that can be used.
What I’ll be using here is OpenLDAP’s pass-through authentication that replaces the user’s password with instructions to use SASL, e.g.:
userPassword: {SASL}username@REALM
This tells OpenLDAP that that password is not local, but instead SASL authentication should be made with username@REALM. On Debian/Ubuntu usually the Cyrus-SASL implementation is used. More information about the Pass-Through authentication is available in the OpenLDAP manual.
To get started with the setup you should have working OpenLDAP + MIT kerberos setup as described in the earlier postings. On top of these the following packages are needed on the machine running OpenLDAP server:
sudo apt-get install sasl2-bin libsasl2-modules-gssapi-mit
To configure saslauthd I used the following settings. From the Ubuntu Lucid defaults I had to change START and MECHANISMS lines.
/etc/default/saslauthd
START=yes DESC="SASL Authentication Daemon" NAME="saslauthd" MECHANISMS="kerberos5" MECH_OPTIONS="" THREADS=5 OPTIONS="-c -m /var/run/saslauthd"
The default installation gives only sasl group access to the socket directory:
user@server:~$ ls -ld /var/run/saslauthd drwx--x--- 2 root sasl 140 2010-03-04 09:47 /var/run/saslauthd
Adding the openldap user to the sasl group gives it access to the socket:
sudo adduser openldap sasl
To get make sure that SASL is installed correctly, run the following command to test the authentication:
testsaslauthd -u user@EDU.EXAMPLE.ORG -p userpassword
If everything works, you should see something like this:
0: OK "Success."
If something went wrong the answer is something like this:
0: NO "authentication failed"
Next test that slapd authentication works:
ldapsearch -D uid=user,ou=people,dc=edu,dc=example,dc=org -W -b dc=edu,dc=example,dc=org
The search should return results normally and authentication should happen against the kerberos server. If authentication doesn’t work, check the /var/log/kdc.log (on debian/ubuntu) and try running saslauthd from command line in debug mode:
sudo /usr/sbin/saslauthd -a kerberos5 -m /var/run/saslauthd -d
Now I’m just left with the problem of having the ntml hashed password for samba in the ldap directory, but at least there’s one less password to manage. Any ideas for the next step?
Veli-Matti Lintu
I guess this reply might be a bit off-topic, but if you replaced MIT kerberos with Heimdal kerberos, you could use the smbk5pwd OpenLDAP overlay to keep the samba password hashes in sync with the kerberos password.
smbk5pwd overlay readme:
http://www.openldap.org/devel/cvsweb.cgi/~checkout~/contrib/slapd-modules/smbk5pwd/README
Thanks for the reminder. I have looked at smbk5pwd and it looks like it could do the job, but as I don’t have previous experience with Heimdal, I haven’t yet tried it. Also I haven’t yet found information about compatibility between MIT and Heimdal kerberos servers and how the change would affect the rest of our infrastucture. Ubuntu doesn’t have the smbk5pwd module compiled by default (https://launchpad.net/bugs/82853), but I’m certainly going to test also this. Any additional hints on this are welcome!
I’m a beginnner.
Would running openLDAP, sasl and Kerberos on the same server make syncing easier and faster as localhosts?
Thanks
The needed server capacity is quite low for these services, so running them all on a single machine is possible in most cases. I haven’t noticed any problems because of this.
I’m having this issue where when I have slapd, kerberos, and the kerberos backend ldap pointing back to the same slapd, I hit a race condition where it appears that the clients ldapbind is blocking an ldapmodify that kerberos is trying to do. But the modify needs to complete before kerberos authorizes the ldapbind.
I can’t find a way to change this locking behavior or by adding concurrency to get around this (other than running it on a different slapd, but that is undesirable)
Did you encounter any problems such as this?