OpenLDAP authenticating against saslauthd
Posted Wed, 08 Feb 2006
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:
While the SASL "slapd.conf" authentication config file is located here:
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 -dThe 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 :do_auth : auth success: [user=psionic] [service=ldap] [realm=CSH.RIT.EDU] [mech=kerberos5] saslauthd :do_request : response: OKWhew! My LDAP Authentication journey is complete. I'll post my configs later once I have a full directory system implemented here. For now, I am elated that gssapi and simple binds both work for eventually authenticating against our Kerberos server.