Search this site





OpenLDAP authenticating against saslauthd

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 installing layers
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 credentials
On 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 db
Googling around will tell you that lots of people put the following in their "slapd.conf" files:
pwcheck_method: saslauthd
saslauthd_path: /var/run/saslauthd/mux
Now, 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 -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: 
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'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.

ldap, round 2

I already know how to setup ldap databases and add objects. Now I needed to figure out how to secure it and hook it to kerberos.

The following in my slapd.conf maps kerberos users to ldap objects.

authz-regexp uid=([^,]*),cn=gssapi,cn=auth 
When you have kerberos ticket and authenticate using SASL, you will bind as 'uid=USER,cn=gssapi,cn=auth' - this is not the proper ldap object for any user on my system. Luckily, I can substitute this dn for a valid one using 'authz-regexp.' What this does, essentially, is do a subquery when you authenticate via SASL and looks for objects in the Users orgunit with a uid=USER. Very very helpful. Now I can get a kerberos ticket and ldap knows who I am:
nightfall(~) [976] % kinit
[email protected]'s Password: 
kinit: NOTICE: ticket renewable lifetime is 0
nightfall(~) [977] % ldapwhoami
SASL/GSSAPI authentication started
SASL username: [email protected]
SASL installing layers
dn:cn=jordan sissel,ou=users,dc=csh,dc=rit,dc=edu
Result: Success (0)
Wonderful! The next step was to allow users to modify their own objects. A short ACL entry in slapd.conf fixes that.
access to attrs=gecos,description,loginShell,mail by self write
This ACL ensures that users only have write access to themselves, and even then only to the attributes listed above. To test this, I did the following:
nightfall(~) [981] % ldapsearch -Q -LLL '(uid=psionic)' 'loginShell'
dn: cn=Jordan Sissel,ou=Users,dc=csh,dc=rit,dc=edu
loginShell: /test/baz/fizz

nightfall(~) [982] % cat myldif
dn: cn=jordan sissel,ou=users,dc=csh,dc=rit,dc=edu
changetype: modify
replace: loginShell
loginShell: Happy Login Shell

nightfall(~) [983] % ldapmodify -Q -f myldif
modifying entry "cn=jordan sissel,ou=users,dc=csh,dc=rit,dc=edu"

ghtfall(~) [984] !1! % !ldapse
ldapsearch -Q -LLL '(uid=psionic)' 'loginShell'
dn: cn=Jordan Sissel,ou=Users,dc=csh,dc=rit,dc=edu
loginShell: Happy Login Shell

Users have write access to their own objects now.

The next step is going to be getting SSL/TLS working. I made a brief attempt at doing that tonight but I failed. Getting some SSLv3 handshake error that is clearly PEBCAK on my part. Oh well, sleep now. More LDAP later.

migrating from nis to ldap, round 1

We at CSH need to move from nis and the many other user information datastores we use to using LDAP instead. To that effort, I have started working on merging our data informations. The first step is importing NIS (passwd/group) information into ldap.

I wrote a script, passwd2ldif, to use NIS passwd information and put it in ldap.

ypcat passwd | ./passwd2ldif > cshusers.ldif
ldapadd -D "cn=happyrootuserthinghere,dc=csh,dc=rit,dc=edu" -f cshusers.ldif
Wait a while, and all users from NIS show up in ldap. I have my laptop looking at ldap for user informatin using nss_ldap:
nightfall(~) [690] % finger -m psionic
Login: psionic                          Name: Jordan Sissel
Directory: /u9/psionic                  Shell: /usr/bin/tcsh
Never logged in.
No Mail.
No Plan.
Pretty simple stuff, so far. Next step is going to involve creating a new schema to support all of the information we currently store in "member profiles." Member profiles is a huge mess of a single mysql table with lots of columns such as "rit_phone," "csh_year," "aol_im," and others. All of that can go to ldap. I'll post more on this later when I figure out what kind of schema we want.