OpenLDAP with saslauthd and Kerberos -
Posted Mon, 01 Jan 2007
Table of Contents
OpenLDAP!
I've been doing research on the internets trying to get OpenLDAP to allow simple binds that can authenticate against Kerberos. Turns out the default SASL support is to only handle GSSAPI when talking to Kerberos V servers. This means you can only authenticate if you have a kerberos tgt. Problem with SASL/GSSAPI is that address book clients aren't going to support much beyond simple authentication over SSL. Thusly, we need a way to use a simple bind over SSL and still authenticate against Kerberos. The LDAP Server's slapd.conf has the following to translate between gssapi auth DNs and real user object DNs: authz-policy from
authz-regexp "^uid=([^,]+),cn=gssapi,cn=auth" "uid=$1,ou=Users,dc=csh,dc=rit,dc=edu"
This allows GSSAPI authentication:
nightfall(~) % ldapwhoami
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (open(/tmp/krb5cc_1001): No such file or directory)
nightfall(~) !1! % kinit psionic
[email protected]'s Password:
kinit: NOTICE: ticket renewable lifetime is 0
nightfall(~) % ldapwhoami
SASL/GSSAPI authentication started
SASL username: [email protected]
SASL SSF: 56
SASL installing layers
dn:uid=psionic,ou=users,dc=csh,dc=rit,dc=edu
Result: Success (0)
I have a TGT and can authenticate to LDAP over SASL (my ldap.conf defaults
to sasl+ssl). However, when you try to do a simple bind:
nightfall(~) % ldapwhoami -x -D 'uid=psionic,ou=users,dc=csh,dc=rit,dc=edu' -W Enter LDAP Password: ldap_bind: Invalid credentialsOn the slapd side, you'll see errors like:
==> bdb_bind: dn: uid=psionic,ou=users,dc=csh,dc=rit,dc=edu SASL Canonicalize [conn=0]: authcid="[email protected]" SASL Canonicalize [conn=0]: authcid="[email protected]" SASL [conn=0] Failure: Could not open db SASL [conn=0] Failure: Could not open dbGoogling around will tell you that lots of people put the following in their "slapd.conf" files:
pwcheck_method: saslauthd saslauthd_path: /var/run/saslauthd/muxNow, you'll recognize that this format of "token: value" doesn't match the normal slapd.conf. There's a reason for this: This isn't OpenLDAP's slapd.conf file. It's the config file for SASL! From what I gather, saslauthd is working similarly to the way PAM works, in that it sees a service trying to use it and uses that particular service's config file. I believe saslauthd comes with a standard Sendmail.conf for example usage. It took me several hours to find this fact out. My slapd SERVER config file is located here:
/usr/local/etc/openldap/slapd.conf While the SASL (saslauthd) "slapd.conf" authentication config file is located here:
/usr/local/lib/sasl2/slapd.conf If you can't find the right place, look for 'Sendmail.conf' somewhere near where you installed sasl or saslauthd. Anyway, once we've added this magic config file and told it to use saslauthd, the SASL library LDAP's slapd is using will now attempt communication with saslauthd over the /var/run/saslauthd/mux socket. I ran saslauthd like this:
/usr/local/sbin/saslauthd -a kerberos5 -d
The directory, /var/run/saslauthd was owned by 'cyrus' and I changed the group
ownership to 'ldap' so that the slapd server (running as 'ldap') could access
the socket. This is a necessary step, else you will get Permission Denied
errors permissions disallow you from accessing the socket or its directory.
Now, once we have saslauthd running, the sasl library slapd.conf, and the moons
aligned, we can perform a simple bind:
nightfall(~) % ldapwhoami -x -D 'uid=psionic,ou=users,dc=csh,dc=rit,dc=edu' -W
Enter LDAP Password:
dn:uid=psionic,ou=Users,dc=csh,dc=rit,dc=edu
Result: Success (0)
saslauthd, in debug mode, will say something meaningful such as:
saslauthd[28910] :do_auth : auth success: [user=psionic] [service=ldap] [realm=CSH.RIT.EDU] [mech=kerberos5]
saslauthd[28910] :do_request : response: OK
Whew! My LDAP Authentication journey is complete. I am elated that gssapi
and simple binds both work for eventually authenticating against our
Kerberos server. I'd post my configs, but the system this was working on
died and I didn't have a backup.