Hi
When is the EXTERNAL mech proposed? I want to use peercred on a slapd instance, but EXTERNAL is not available:
$ ldapsearch -xLLLH ldapi:/// -s base -b '' supportedSASLMechanisms dn: supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: PLAIN supportedSASLMechanisms: LOGIN
I have other machines when it shows up without a hassle. Where is the setting that cause it to be proposed?
On 12/13/12 17:26 +0000, Emmanuel Dreyfus wrote:
Hi
When is the EXTERNAL mech proposed? I want to use peercred on a slapd instance, but EXTERNAL is not available:
$ ldapsearch -xLLLH ldapi:/// -s base -b '' supportedSASLMechanisms dn: supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: PLAIN supportedSASLMechanisms: LOGIN
I have other machines when it shows up without a hassle. Where is the setting that cause it to be proposed?
Look at your sasl slapd.conf if it exists (e.g. /usr/lib/sasl2/slapd.conf, or /etc/sasl/slapd.conf).
If you have a mech_list listed within that file, then either comment it out, or add EXTERNAL to it.
Check your syslog (including the auth facility) for any errors.
On Thu, Dec 13, 2012 at 11:46:57AM -0600, Dan White wrote:
Look at your sasl slapd.conf if it exists (e.g. /usr/lib/sasl2/slapd.conf, or /etc/sasl/slapd.conf).
If you have a mech_list listed within that file, then either comment it out, or add EXTERNAL to it.
That fixes it. The goal is to let the slapd pseudo-user reconnect to slapd so that SASL LDAPDB plugin works. It does connect but LDAPDB does not work. here is the config:
sasl2/slapd.conf: pwcheck_method: auxprop auxprop_plugin: ldapdb mech_list: EXTERNAL DIGEST-MD5 PLAIN LOGIN ldapdb_uri: ldapi:/// ldapdb_id: cn=ldap.example.net,ou=pseudo-users,dc=example,dc=net ldapdb_mech: EXTERNAL log_level: 7
in openldap/dlapd.conf: authz-regexp "uidNumber=401,cn=peercred,cn=external,cn=auth" "cn=ldap.example.net,ou=pseudo-users,dc=example,dc=net" authz-regexp uid=([^,]*),cn=external,cn=auth "ldap:///dc=example,dc=net??sub?(uid=$1)
in /etc/passwd: slapd:*:401:1000:openldap-server slapd user:/nonexistent:/sbin/nologin
In LDAP DIT: dn: cn=ldap.example.net,ou=pseudo-users,dc=example,dc=net objectClass: organizationalRole cn: ldap.example.net ou: pseudo-users authzTo: {0}dn:*
This works: # su -m slapd -c 'ldapwhoami -Y EXTERNAL -H ldapi:///' SASL/EXTERNAL authentication started SASL username: gidNumber=1000+uidNumber=401,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:cn=ldap.example.net,ou=pseudo-users,dc=example,dc=net
This also works: # su -m slapd -c 'ldapwhoami -X u:someone -Y EXTERNAL -H ldapi:///' SASL/EXTERNAL authentication started SASL username: u:someone SASL SSF: 0 dn:uid=someone,dc=example,dc=net
However this does not work: # su -m someone -c 'ldapwhoami -U uid=someone,dc=example,dc=net \ -Y PLAIN -H ldaps://ldap.example.com'
logs say: conn=2455 op=0 BIND dn="uid=someone,dc=example,dc=net" method=163 SASL [conn=2455] Failure: Password verification failed conn=2455 op=0 RESULT tag=97 err=49 text=SASL(-13): user not found: Password verification failed conn=2455 op=1 UNBIND
I must be missing how the LDAPDB plugin works. Any hint?
On 12/17/12 16:40 +0000, Emmanuel Dreyfus wrote:
On Thu, Dec 13, 2012 at 11:46:57AM -0600, Dan White wrote:
Look at your sasl slapd.conf if it exists (e.g. /usr/lib/sasl2/slapd.conf, or /etc/sasl/slapd.conf).
If you have a mech_list listed within that file, then either comment it out, or add EXTERNAL to it.
That fixes it. The goal is to let the slapd pseudo-user reconnect to slapd so that SASL LDAPDB plugin works. It does connect but LDAPDB does not work. here is the config:
sasl2/slapd.conf: pwcheck_method: auxprop auxprop_plugin: ldapdb mech_list: EXTERNAL DIGEST-MD5 PLAIN LOGIN ldapdb_uri: ldapi:/// ldapdb_id: cn=ldap.example.net,ou=pseudo-users,dc=example,dc=net ldapdb_mech: EXTERNAL log_level: 7
You should not use the ldapdb auxprop plugin within slapd's sasl config. You should be using 'slapd' instead, which is the default (it's an internal auxprop plugin distributed with OpenLDAP).
If you are running version 2.4.17 or newer, the 'auxprop_plugin' option is ignored anyway, and you must configure olcSaslAuxprops if you really wish to use a different auxprop plugin.
in openldap/dlapd.conf: authz-regexp "uidNumber=401,cn=peercred,cn=external,cn=auth" "cn=ldap.example.net,ou=pseudo-users,dc=example,dc=net" authz-regexp uid=([^,]*),cn=external,cn=auth "ldap:///dc=example,dc=net??sub?(uid=$1)
in /etc/passwd: slapd:*:401:1000:openldap-server slapd user:/nonexistent:/sbin/nologin
In LDAP DIT: dn: cn=ldap.example.net,ou=pseudo-users,dc=example,dc=net objectClass: organizationalRole cn: ldap.example.net ou: pseudo-users authzTo: {0}dn:*
This works: # su -m slapd -c 'ldapwhoami -Y EXTERNAL -H ldapi:///' SASL/EXTERNAL authentication started SASL username: gidNumber=1000+uidNumber=401,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:cn=ldap.example.net,ou=pseudo-users,dc=example,dc=net
This also works: # su -m slapd -c 'ldapwhoami -X u:someone -Y EXTERNAL -H ldapi:///' SASL/EXTERNAL authentication started SASL username: u:someone SASL SSF: 0 dn:uid=someone,dc=example,dc=net
However this does not work: # su -m someone -c 'ldapwhoami -U uid=someone,dc=example,dc=net \ -Y PLAIN -H ldaps://ldap.example.com'
logs say: conn=2455 op=0 BIND dn="uid=someone,dc=example,dc=net" method=163 SASL [conn=2455] Failure: Password verification failed conn=2455 op=0 RESULT tag=97 err=49 text=SASL(-13): user not found: Password verification failed conn=2455 op=1 UNBIND
I must be missing how the LDAPDB plugin works. Any hint?
That command doesn't make sense. '-U uid=someone,dc=example,dc=net' should be '-U someone' instead, and you should create new authz-regexp rules to map a sasl PLAIN identity of 'someone' to uid=someone,dc=example,dc=net.
You could also do:
su -m someone -c 'ldapwhoami -Y EXTERNAL -H ldapi:///'
with an appropriately written authz-regexp rule. 'someone' would need unix file permissions to access your ldapi unix socket.
On Mon, Dec 17, 2012 at 11:08:11AM -0600, Dan White wrote:
You should not use the ldapdb auxprop plugin within slapd's sasl config. You should be using 'slapd' instead, which is the default (it's an internal auxprop plugin distributed with OpenLDAP).
If you are running version 2.4.17 or newer, the 'auxprop_plugin' option is ignored anyway
Right, I removed it, but it should not change anything. And indeed it does not change anything.
# su -m someone -c 'ldapwhoami -U uid=someone,dc=example,dc=net \ -Y PLAIN -H ldaps://ldap.example.net'
That command doesn't make sense. '-U uid=someone,dc=example,dc=net' should be '-U someone' instead,
I trired that and got the same result.
and you should create new authz-regexp rules to map a sasl PLAIN identity of 'someone' to uid=someone,dc=example,dc=net.
I did this. With debug acl level, I can see that the uid=someone,dc=example,dc=net is tired for auth, but it fails.
You could also do: su -m someone -c 'ldapwhoami -Y EXTERNAL -H ldapi:///' with an appropriately written authz-regexp rule. 'someone' would need unix file permissions to access your ldapi unix socket.
That works, but what I am looking for is to get SASL PLAIN working over the network with TLS. I want to use authzid.
On 12/17/12 17:28 +0000, Emmanuel Dreyfus wrote:
On Mon, Dec 17, 2012 at 11:08:11AM -0600, Dan White wrote:
# su -m someone -c 'ldapwhoami -U uid=someone,dc=example,dc=net \ -Y PLAIN -H ldaps://ldap.example.net'
That command doesn't make sense. '-U uid=someone,dc=example,dc=net' should be '-U someone' instead,
I trired that and got the same result.
and you should create new authz-regexp rules to map a sasl PLAIN identity of 'someone' to uid=someone,dc=example,dc=net.
I did this. With debug acl level, I can see that the uid=someone,dc=example,dc=net is tired for auth, but it fails.
What SASL errors do you see? Check your syslog (auth facility).
Verify that your password, stored within userPassword, is in plain text (when uudecoded). I do not recommend attempting to use 'pwcheck_method: auprop-hashed' with the slapd auxprop.
If not, you could inject saslauthd (with ldap backend) into the mix to support hashed password storage for SASL PLAIN and LOGIN binds. However, DIGEST-MD5 will not work with saslauthd.
Dan White dwhite@olp.net wrote:
Verify that your password, stored within userPassword, is in plain text (when uudecoded). I do not recommend attempting to use 'pwcheck_method: auprop-hashed' with the slapd auxprop.
If not, you could inject saslauthd (with ldap backend) into the mix to support hashed password storage for SASL PLAIN and LOGIN binds. However, DIGEST-MD5 will not work with saslauthd.
That is the missing bit: I though LDAPDB was able to check hashed passwords with PLAIN and LOGIN. I will retry with saslauthd.
On Mon, Dec 17, 2012 at 12:46:17PM -0600, Dan White wrote:
Verify that your password, stored within userPassword, is in plain text (when uudecoded). I do not recommend attempting to use 'pwcheck_method: auprop-hashed' with the slapd auxprop.
I confirm it was the problem: using saslauthd it works fine.
Here is my setup for reference. It does not use EXTERNAL on ldapi:/// after all
/usr/pkg/etc/openldap/slapd.conf: authz-policy any authz-regexp uid=([^,]*),cn=(plain|login|otp|external),cn=auth ldap:///dc=example,dc=net??sub?(uid=$1)
/usr/pkg/lib/sasl2/slapd.conf pwcheck_method: saslauthd saslauthd_path: /var/run/saslauthd/mux mech_list: PLAIN LOGIN
/usr/pkg/etc/saslauthd.conf ldap_servers: ldaps://ldap.example.net ldap_search_base: dc=example,dc=net ldap_use_sasl: no
saslauthd is built with LDAP support and is started as: saslauthd -a ldap
Testing without slapd: testsaslauthd -u someone -p password -s slapd
Now using authzid. In DIT: dn: uid=someone,dc=example,dc=net authzFrom: {0}dn:uid=manu,dc=example,dc=net
Everything is fine: $ ldapwhoami -Y PLAIN -X u:someone -U manu SASL/PLAIN authentication started Please enter your password: [manu's password] SASL username: u:someone SASL SSF: 0 dn:uid=someone,dc=example,dc=net
openldap-technical@openldap.org
-
Dan White -
Emmanuel Dreyfus -
manu＠netbsd.org