Hi all,
after spending several days fighting with OpenLDAP2.3/SASL setup I'm finally at point where both sample-client/server and ldapwhoami work for a user who's got his password stored in cleartext in LDAP's userPassword field. I'm using TLS and both PLAIN and DIGEST-MD5 work. However, for a user with his password stored as SSHA has in LDAP's userPassword neither of those work.
It seems that DIGEST-MD5 can only work if both sides have access to the cleartext password, right? Thus, it was expected that DIGEST-MD5 can't work.
But I'm out of clues with PLAIN (over TLS, using a self-signed certificate) as why it doesn't work for a user who's password is in SSHA. The users are testusers I entered, the ldif file used was 1:1, only the uids and passwords were different. I am still missing some basic principle of SASL or what's going on here?
The reason I'm writing to the OpenLDAP mailing list is that with the user failing to authenticate slapd is logging errors that are not present with the ok'd user.
ldapwhoami says:
root@localhost:~# ldapwhoami -U qwe -Y PLAIN -ZZ SASL/PLAIN authentication started Please enter your password: SASL username: qwe SASL SSF: 0 dn:uid=qwe,ou=people,dc=intra Result: Success (0) root@localhost:~# ldapwhoami -U dq -Y PLAIN -ZZ SASL/PLAIN authentication started Please enter your password: ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: Password verification failed root@localhost:~#
And the server says in the latter case:
do_sasl_bind: dn () mech PLAIN ==> sasl_bind: dn="" mech=PLAIN datalen=6 SASL Canonicalize [conn=1]: authcid="dq" slap_sasl_getdn: conn 1 id=dq [len=2] => ldap_dn2bv(16) <= ldap_dn2bv(uid=dq,cn=PLAIN,cn=auth)=0 slap_sasl_getdn: u:id converted to uid=dq,cn=PLAIN,cn=auth
dnNormalize: <uid=dq,cn=PLAIN,cn=auth>
=> ldap_bv2dn(uid=dq,cn=PLAIN,cn=auth,0) <= ldap_bv2dn(uid=dq,cn=PLAIN,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=dq,cn=plain,cn=auth)=0 <<< dnNormalize: <uid=dq,cn=plain,cn=auth> ==>slap_sasl2dn: converting SASL name uid=dq,cn=plain,cn=auth to a DN slap_authz_regexp: converting SASL name uid=dq,cn=plain,cn=auth slap_authz_regexp: converted SASL name to uid=dq,ou=People,dc=intra slap_parseURI: parsing uid=dq,ou=People,dc=intra ldap_url_parse_ext(uid=dq,ou=People,dc=intra)
dnNormalize: <uid=dq,ou=People,dc=intra>
=> ldap_bv2dn(uid=dq,ou=People,dc=intra,0) <= ldap_bv2dn(uid=dq,ou=People,dc=intra)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=dq,ou=people,dc=intra)=0 <<< dnNormalize: <uid=dq,ou=people,dc=intra> <==slap_sasl2dn: Converted SASL name to uid=dq,ou=people,dc=intra slap_sasl_getdn: dn:id converted to uid=dq,ou=people,dc=intra SASL Canonicalize [conn=1]: slapAuthcDN="uid=dq,ou=people,dc=intra" SASL Canonicalize [conn=1]: authcid="dq" slap_sasl_getdn: conn 1 id=dq [len=2] => ldap_dn2bv(16) <= ldap_dn2bv(uid=dq,cn=PLAIN,cn=auth)=0 slap_sasl_getdn: u:id converted to uid=dq,cn=PLAIN,cn=auth
dnNormalize: <uid=dq,cn=PLAIN,cn=auth>
=> ldap_bv2dn(uid=dq,cn=PLAIN,cn=auth,0) <= ldap_bv2dn(uid=dq,cn=PLAIN,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=dq,cn=plain,cn=auth)=0 <<< dnNormalize: <uid=dq,cn=plain,cn=auth> ==>slap_sasl2dn: converting SASL name uid=dq,cn=plain,cn=auth to a DN slap_authz_regexp: converting SASL name uid=dq,cn=plain,cn=auth slap_authz_regexp: converted SASL name to uid=dq,ou=People,dc=intra slap_parseURI: parsing uid=dq,ou=People,dc=intra ldap_url_parse_ext(uid=dq,ou=People,dc=intra)
dnNormalize: <uid=dq,ou=People,dc=intra>
=> ldap_bv2dn(uid=dq,ou=People,dc=intra,0) <= ldap_bv2dn(uid=dq,ou=People,dc=intra)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=dq,ou=people,dc=intra)=0 <<< dnNormalize: <uid=dq,ou=people,dc=intra> <==slap_sasl2dn: Converted SASL name to uid=dq,ou=people,dc=intra slap_sasl_getdn: dn:id converted to uid=dq,ou=people,dc=intra SASL Canonicalize [conn=1]: slapAuthcDN="uid=dq,ou=people,dc=intra" => bdb_search bdb_dn2entry("uid=dq,ou=people,dc=intra") => bdb_dn2id("uid=dq,ou=people,dc=intra") <= bdb_dn2id: got id=0x0000007b entry_decode: "uid=dq,ou=People,dc=intra" <= entry_decode(uid=dq,ou=People,dc=intra) base_candidates: base: "uid=dq,ou=people,dc=intra" (0x0000007b) => test_filter PRESENT => access_allowed: auth access to "uid=dq,ou=People,dc=intra" "objectClass" requested => acl_get: [2] attr objectClass => acl_mask: access to entry "uid=dq,ou=People,dc=intra", attr "objectClass" requested => acl_mask: to all values by "", (=0) <= check a_dn_pat: * <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => access_allowed: auth access granted by read(=rscxd) <= test_filter 6 => access_allowed: auth access to "uid=dq,ou=People,dc=intra" "userPassword" requested => acl_get: [1] attr userPassword => acl_mask: access to entry "uid=dq,ou=People,dc=intra", attr "userPassword" requested => acl_mask: to all values by "", (=0) <= check a_dn_pat: self <= check a_dn_pat: * <= acl_mask: [2] applying auth(=xd) (stop) <= acl_mask: [2] mask: auth(=xd) => access_allowed: auth access granted by auth(=xd) slap_ap_lookup: str2ad(cmusaslsecretPLAIN): attribute type undefined send_ldap_result: conn=1 op=1 p=3 send_ldap_result: err=0 matched="" text="" SASL [conn=1] Failure: Password verification failed send_ldap_result: conn=1 op=1 p=3 send_ldap_result: err=49 matched="" text="SASL(-13): user not found: Password verification failed" send_ldap_response: msgid=2 tag=97 err=49
So why I'm seeing "str2ad(cmusaslsecretPLAIN): attribute type undefined" with a user who's password is stored as SSHA?
Any hints would be highly appreciated, I've really read the docs, experimented with different configs, and slow I've been stumbling along but this seems to be just too hard to grok.
Thanks!
____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Daniel Qarras dqarras@yahoo.com writes:
Hi all,
after spending several days fighting with OpenLDAP2.3/SASL setup I'm finally at point where both sample-client/server and ldapwhoami work for a user who's got his password stored in cleartext in LDAP's userPassword field. I'm using TLS and both PLAIN and DIGEST-MD5 work. However, for a user with his password stored as SSHA has in LDAP's userPassword neither of those work.
It seems that DIGEST-MD5 can only work if both sides have access to the cleartext password, right? Thus, it was expected that DIGEST-MD5 can't work.
But I'm out of clues with PLAIN (over TLS, using a self-signed certificate) as why it doesn't work for a user who's password is in SSHA. The users are testusers I entered, the ldif file used was 1:1, only the uids and passwords were different. I am still missing some basic principle of SASL or what's going on here?
[...]
Think twice! This is not an OpenLDAP issue but a SASL issue, ask on a sasl mailinglist how sasl machanisms are designed and how they retrieve credentials.
-Dieter
Daniel Qarras wrote:
Hi all,
after spending several days fighting with OpenLDAP2.3/SASL setup I'm finally at point where both sample-client/server and ldapwhoami work for a user who's got his password stored in cleartext in LDAP's userPassword field. I'm using TLS and both PLAIN and DIGEST-MD5 work. However, for a user with his password stored as SSHA has in LDAP's userPassword neither of those work.
It seems that DIGEST-MD5 can only work if both sides have access to the cleartext password, right? Thus, it was expected that DIGEST-MD5 can't work.
But I'm out of clues with PLAIN (over TLS, using a self-signed certificate) as why it doesn't work for a user who's password is in SSHA. The users are testusers I entered, the ldif file used was 1:1, only the uids and passwords were different. I am still missing some basic principle of SASL or what's going on here?
You can use saslauthd to authenticate PLAIN. I'm using saslauthd/pam with libpam_ldap to to accomplish this during a transition period where my passwords are hashed.
You'd need to set the pwcheck_method to include saslauthd in your slapd.conf *sasl* config file to support it.
- Dan
But I'm out of clues with PLAIN (over TLS, using a self-signed certificate) as why it doesn't work for a user who's password is in SSHA. The users are testusers I entered, the ldif file used was 1:1, only the uids and passwords were different. I am still missing some basic principle of SASL or what's going on here?
You can use saslauthd to authenticate PLAIN. I'm using saslauthd/pam with libpam_ldap to to accomplish this during a transition period where my passwords are hashed.
You'd need to set the pwcheck_method to include saslauthd in your slapd.conf *sasl* config file to support it.
It works! Dan, THANKS! You really made my day!
As googling around reveals, people have been asking these same questions for the past five *years* so I think I owe to post my config below.
saslauthd.conf, starting the daemon with saslauthd -d -a ldap
ldap_servers: ldap://10.0.0.1/ ldap_start_tls: yes ldap_search_base: dc=intra
sasl2/slapd.conf (first line just to make sure slapd only uses its internal ldapdb)
auxprop_plugin: slapd pwcheck_method: saslauthd saslauthd_path: /var/run/saslauthd/mux
openldap/slapd.conf (relevant portions):
authz-regexp uid=([^,]*),cn=PLAIN,cn=auth uid=$1,ou=People,dc=intra
It always a bit depressing to see how things come together after wasting several days of one's life but at least I've finally got this part working and can continue on my merry way...
Thanks!
____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
openldap-software@openldap.org
-
Dan White -
Daniel Qarras -
Dieter Kluenter