I've been trying to get Pass-Through authentication to work using a userPassword attribute of the form {SASL}username@realm. At this point I'm guessing but is there a way to tell slapd what pathspec to use to talk to saslauthd? (I'm guessing maybe it's using one path but saslauthd is using a different one for the socket file)
I've got saslauthd running ok and can authenticate using testsaslauthd so I'm fairly sure I'm ok there. And I've got openldap compiled with --enable-spasswd option so it ought to support the SASL pass-through option, right?
I ran saslauthd with debugging on so I can see every auth request and whether it succeeds or fails and I can see it when testsaslauth connects and succeeds. But when I try to bind to slapd using the DN whose userPassword is {SASL}bbice@ldap the authentication to slapd fails and saslauthd doesn't show any authentication attempt at all. It's as if it's not even trying (or can't find) saslauthd.
I ran slapd with the -d 255 option and saved the output to a file. Here's all the lines containing the string sasl:
dnPretty: <cn=SASL>
=> ldap_bv2dn(cn=SASL,0) <= ldap_bv2dn(cn=SASL)=0 <= ldap_dn2bv(cn=SASL)=0 <<< dnPretty: <cn=SASL>
dnNormalize: <cn=SASL>
<<< dnNormalize: <cn=sasl> ldap_sasl_bind_s ldap_sasl_bind SASL Canonicalize [conn=1000]: authcid="bbice@ldap" SASL Canonicalize [conn=1000]: authcid="bbice@ldap" SASL Canonicalize [conn=1001]: authcid="bbice@ldap" SASL Canonicalize [conn=1001]: authcid="bbice@ldap"
So if I'm reading that right, slapd does see that it's supposed to hand off the authentication to saslauthd and it has picked out the username and realm. But it doesn't seem to be connecting to or using saslauthd.
Any ideas? What am I missing here?
Brent Bice bbice@sgi.com
Brent Bice bbice@sgi.com writes:
I've been trying to get Pass-Through authentication to work using a userPassword attribute of the form {SASL}username@realm. At this point I'm guessing but is there a way to tell slapd what pathspec to use to talk to saslauthd? (I'm guessing maybe it's using one path but saslauthd is using a different one for the socket file)
I've got saslauthd running ok and can authenticate using testsaslauthd so I'm fairly sure I'm ok there. And I've got openldap compiled with --enable-spasswd option so it ought to support the SASL pass-through option, right?
I ran saslauthd with debugging on so I can see every auth request and whether it succeeds or fails and I can see it when testsaslauth connects and succeeds. But when I try to bind to slapd using the DN whose userPassword is {SASL}bbice@ldap the authentication to slapd fails and saslauthd doesn't show any authentication attempt at all. It's as if it's not even trying (or can't find) saslauthd.
I ran slapd with the -d 255 option and saved the output to a file. Here's all the lines containing the string sasl:
dnPretty: <cn=SASL>
=> ldap_bv2dn(cn=SASL,0) <= ldap_bv2dn(cn=SASL)=0 <= ldap_dn2bv(cn=SASL)=0 <<< dnPretty: <cn=SASL>
dnNormalize: <cn=SASL>
<<< dnNormalize: <cn=sasl> ldap_sasl_bind_s ldap_sasl_bind SASL Canonicalize [conn=1000]: authcid="bbice@ldap" SASL Canonicalize [conn=1000]: authcid="bbice@ldap" SASL Canonicalize [conn=1001]: authcid="bbice@ldap" SASL Canonicalize [conn=1001]: authcid="bbice@ldap"
So if I'm reading that right, slapd does see that it's supposed to hand off the authentication to saslauthd and it has picked out the username and realm. But it doesn't seem to be connecting to or using saslauthd.
Any ideas? What am I missing here?
Did you create a lib/sasl2/slapd.conf, or wherever your sasl configuration files are located?
-Dieter
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
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.
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?
Brent
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.
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.
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.
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
--On Thursday, August 05, 2010 2:00 PM -0700 Brent Bice bbice@sgi.com wrote:
I also notice when I export this record as an LDIF file the userPassword attribute has been hashed: userPassword:: e1NBU0x9YmJpY2VAbGRhcA==
This is not a hash. This is base64 encoding, as has been discussed a few thousand times on this list. ;) You simply need to decode it to see the actual value. This is per RFC.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Thursday, August 05, 2010 2:00 PM -0700 Brent Bice bbice@sgi.com wrote:
I also notice when I export this record as an LDIF file the userPassword attribute has been hashed: userPassword:: e1NBU0x9YmJpY2VAbGRhcA==
This is not a hash. This is base64 encoding, as has been discussed a few thousand times on this list. ;) You simply need to decode it to see the actual value. This is per RFC.
(slaps forehead) I realized that a bit after I sent the email. I was thinking perhaps I didn't have the userPassword set right to convince slapd to use SASL pass-through authentication, but... it is set right so I still don't know why it's not contacting saslauthd. Hmph.
Dan White wrote: See if you can find out what --with-configdir option was passed to your cyrus sasl ./configure when it was compiled, which defaults to /usr/lib/sasl2 (regardless of where the libraries are actually installed).
I built all the sasl, openldap, openssl, zlib, etc from source. On all of them I set a --prefix to the same place (a directory containing this version of our LDAP server binaries). So I didn't specify a --with-configdir option but I'd expect it'd default to the prefix_dir/lib/sasl2/.
Aha! The config.status file contains this, however: s,@configdir@,/usr/lib/sasl2:/etc/sasl2,;t t
So perhaps it's not using my prefix_dir/lib/sasl2/slapd.conf file. I'll drop something in /usr/lib/sasl2 just to see if this is the case or I'll rebuild using an explicit --with-configdir.
If you were not creating it in the correct location, then libsasl would default to using sasldb auxprop for authentication. You could create a test user:
saslpasswd -c bbice
to see if sasldb is being used.
I don't think testsaslauthd uses libsasl itself, so if none of that works, you may still need to verify your libsasl is installed and linked correctly. sample-server and sample-client might help (create a /usr/lib/sasl2/sample.conf).
You might also try a direct SASL bind against the server to see if that works. Add 'sasl-secprops none' to your slapd.conf, then do:
ldapwhoami -Y PLAIN -U bbice ...
which should also use saslauthd to authenticate, with pwcheck_method: saslauthd.
Thanks for the tips! I'll try these out too.
Brent
On 05/08/10 14:00 -0700, Brent Bice wrote:
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.
Is that /usr/lib/sasl2/slapd.conf?
See if you can find out what --with-configdir option was passed to your cyrus sasl ./configure when it was compiled, which defaults to /usr/lib/sasl2 (regardless of where the libraries are actually installed).
If you were not creating it in the correct location, then libsasl would default to using sasldb auxprop for authentication. You could create a test user:
saslpasswd -c bbice
to see if sasldb is being used.
I don't think testsaslauthd uses libsasl itself, so if none of that works, you may still need to verify your libsasl is installed and linked correctly. sample-server and sample-client might help (create a /usr/lib/sasl2/sample.conf).
You might also try a direct SASL bind against the server to see if that works. Add 'sasl-secprops none' to your slapd.conf, then do:
ldapwhoami -Y PLAIN -U bbice ...
which should also use saslauthd to authenticate, with pwcheck_method: saslauthd.
Many thanks to everyone here. I've got it working now. The first part of the solution was finding out (thanks Dan!) that cyrus-sasl doesn't use prefix_dir/lib/sasl2/slapd.conf when you build from source unless you explicitly set --with-configdir (Aha!).
After temporarily linking /usr/lib/sasl2 to my prefix_dir/lib/sasl2, it still wasn't working but that was because I'd messed with so many different settings in the sasl slapd.conf. Re-reading the openldap docs on pass-thru authentication and going back to this worked: mech_list: plain pwcheck_method: saslauthd saslauthd_path: /var/state/saslauthd/mux sasl-secprops: none
Brent
Dan White wrote:
On 05/08/10 14:00 -0700, Brent Bice wrote:
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.
Is that /usr/lib/sasl2/slapd.conf?
See if you can find out what --with-configdir option was passed to your cyrus sasl ./configure when it was compiled, which defaults to /usr/lib/sasl2 (regardless of where the libraries are actually installed).
If you were not creating it in the correct location, then libsasl would default to using sasldb auxprop for authentication. You could create a test user:
saslpasswd -c bbice
to see if sasldb is being used.
I don't think testsaslauthd uses libsasl itself, so if none of that works, you may still need to verify your libsasl is installed and linked correctly. sample-server and sample-client might help (create a /usr/lib/sasl2/sample.conf).
You might also try a direct SASL bind against the server to see if that works. Add 'sasl-secprops none' to your slapd.conf, then do:
ldapwhoami -Y PLAIN -U bbice ...
which should also use saslauthd to authenticate, with pwcheck_method: saslauthd.
openldap-technical@openldap.org
-
Brent Bice -
Dan White -
Dieter Kluenter -
Quanah Gibson-Mount