Dan White wrote:
On 04/08/10 14:54 -0700, Brent Bice wrote:
Dieter Kluenter wrote:
Did you create a lib/sasl2/slapd.conf, or wherever your sasl configuration files are located?
I created a lib/sasl2/slapd.conf file again and in it specified: pwcheck_method: saslauthd saslauthd_path: /var/state/saslauthd/mux
If testsaslauth works without specifying a '-f' option, then you shouldn't need to specify saslauthd_path.
I didn't think so either. I put it in just in case slapd was trying to figure out where the socket was by reading this file.
And I confirmed that that is, indeed, the path that saslauthd is listening on (it shows when I run saslauthd with the -d -V flags). But when I ask OpenLDAP to authenticate a user whose userPassword attribute is {SASL}bbice@ldap the saslauthd daemon shows no sign of having received an auth request.
Make sure the user that slapd is running under has permissions to access the saslauthd mux. You may need to do a 'addgroup openldap sasl' or something similar to give it permissions.
Yep. At the moment saslauthd and slapd are both being run by the same account (they're both running as bbice right now). The socket that got created should definitely be writable by slapd running as the bbice user: srwxrwxrwx 1 bbice dco 0 2010-08-05 13:33 /var/state/saslauthd/mux
If I run testsaslauthd -u bbice, however, the authentication works ok and saslauthd shows testsaslauthd connecting to it. So it appears slapd isn't contacting saslauthd at all? How does slapd determine what path to use for the saslauthd socket? lib2/sasl/slapd.conf? Or saslauthd.conf?
The location is compiled into the sasl glue library at configure time, but can be changed with the saslauthd_path config option.
Since I didn't see any config options in OpenLDAP's slapd.conf to specify it, I figured some way of finding the socket must be built into the SASL libs but I was just guessing.
So... I'm stumped. I took another look at the user record I'm trying to authenticate with. I reset the userPassword attribute with this LDIF file: dn: uid=46313,ou=Employees,ou=People,dc=sgi,dc=com changetype: modify replace: userPassword userPassword: {SASL}bbice@ldap
So that ought to tell slapd to contact saslauthd whenever someone tries to authenticate against this DN, right? I also notice when I export this record as an LDIF file the userPassword attribute has been hashed: userPassword:: e1NBU0x9YmJpY2VAbGRhcA==
And even if I use a tool like DirectoryStudio and select a hash of "Plaintext" and enter in {SASL}bbice@ldap the userPassword attribute still gets exported hashed. Would this matter? Perhaps slapd isn't contacting SASL because I haven't set the userPassword attribute correctly???
Brent