Research and Development

OpenLDAP Authentication With Kerberos Backend Using SASL

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:

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

Comments