HI!
I'd like let users authenticate via SASL/PLAIN or SASL/LOGIN so they do not have to deal with full bind-DNs, my client does not have to search the user and to avoid slapo-rwm.
Yes, the connection is protected with TLS. Later it has to work with hashed userPassword values. It should be feasible. Or not?
Test system: latest OpenLDAP RE24 cyrus-sasl-2.1.25-28.1.2.x86_64 shipped with openSUSE 13.1
In my test setup everything works with DIGEST-MD5 but not with PLAIN or LOGIN (clear-text userPassword value for testing). The log shows that the SASL username gets mapped by authz-regexp to the correct LDAP user entry:
52f60408 <==slap_sasl2dn: Converted SASL name to uid=user,ou=dept,o=example 52f60408 slap_sasl_getdn: dn:id converted to uid=user,ou=dept,o=example
But SASL does not use "pwcheck_method: slapd" for mechs PLAIN/LOGIN but works with DIGEST-MD5:
$ ldapwhoami -H ldapi:/// -Y DIGEST-MD5 -U user -w secret SASL/DIGEST-MD5 authentication started SASL username: user SASL SSF: 128 SASL data security layer installed. dn:uid=user,ou=dept,o=example $ ldapwhoami -H ldapi:/// -Y LOGIN -U user -w secret SASL/LOGIN authentication started ldap_sasl_interactive_bind_s: Authentication method not supported (7) additional info: SASL(-4): no mechanism available: checkpass failed $ ldapwhoami -H ldapi:/// -Y PLAIN -U user -w secret SASL/PLAIN authentication started ldap_sasl_interactive_bind_s: Authentication method not supported (7) additional info: SASL(-4): no mechanism available: Password verification failed
The trace shows for PLAIN or LOGIN (running slapd -d config,stats,stats2,acl,args,trace):
SASL [conn=1002] Error: unknown password verifier(s) slapd
My /usr/lib64/sasl.conf contains: ---------------------------- snip ---------------------------- pwcheck_method: slapd mech_list: plain login digest-md5 external ---------------------------- snip ---------------------------- I've checked that this is the right file by setting "pwcheck_method: foobar" which appears in the logs then.
My slapd.conf contains: ---------------------------- snip ---------------------------- disallow bind_anon require bind LDAPv3 strong
# SSF value for ldapi:// localSSF 256 # minimum required SSF value (security strength factor) security transport=128 sasl=0 # Since we require TLS we can relax this sasl-secprops none,minssf=0 ---------------------------- snip ----------------------------
Any clue?
Ciao, Michael.
Michael Ströder wrote:
The trace shows for PLAIN or LOGIN (running slapd -d config,stats,stats2,acl,args,trace):
SASL [conn=1002] Error: unknown password verifier(s) slapd
My /usr/lib64/sasl.conf contains: ---------------------------- snip ---------------------------- pwcheck_method: slapd mech_list: plain login digest-md5 external ---------------------------- snip ---------------------------- I've checked that this is the right file by setting "pwcheck_method: foobar" which appears in the logs then.
There is no such pwcheck_method. The SASL error message is correct.
Read the Cyrus SASL docs for pwcheck_method.
Howard Chu wrote:
Michael Ströder wrote:
The trace shows for PLAIN or LOGIN (running slapd -d config,stats,stats2,acl,args,trace):
SASL [conn=1002] Error: unknown password verifier(s) slapd
My /usr/lib64/sasl.conf contains: ---------------------------- snip ---------------------------- pwcheck_method: slapd mech_list: plain login digest-md5 external ---------------------------- snip ---------------------------- I've checked that this is the right file by setting "pwcheck_method: foobar" which appears in the logs then.
There is no such pwcheck_method. The SASL error message is correct.
Ouch! Thanks!
http://cyrusimap.org/docs/cyrus-sasl/2.1.25/options.php
"and those that are therefore most commonly misunderstood are pwcheck_method and auxprop_plugin"
Ah, yes.
But... the methods 'authdaemond' and 'saslauthd' are not an option since I don't want to run another demon. 'pwcheck' does also not seem to be avaiable.
It only works with clear-text userPassword values when setting pwcheck_method: auxprop
Obviously I don't want that.
Ciao, Michael.
On 02/08/14 11:45 +0100, Michael Ströder wrote:
I'd like let users authenticate via SASL/PLAIN or SASL/LOGIN so they do not have to deal with full bind-DNs, my client does not have to search the user and to avoid slapo-rwm.
Yes, the connection is protected with TLS. Later it has to work with hashed userPassword values. It should be feasible. Or not?
Your options here are saslauthd or authdaemond, both of which advertise ldap backend support. Or, you can run saslauthd with its pam backend, which could authenticate against an ldap pam module, such as nssov.
Hallo Michael,
Am Sat, 08 Feb 2014 11:45:52 +0100 schrieb Michael Ströder michael@stroeder.com:
HI!
I'd like let users authenticate via SASL/PLAIN or SASL/LOGIN so they do not have to deal with full bind-DNs, my client does not have to search the user and to avoid slapo-rwm.
Yes, the connection is protected with TLS. Later it has to work with hashed userPassword values. It should be feasible. Or not?
Test system: latest OpenLDAP RE24 cyrus-sasl-2.1.25-28.1.2.x86_64 shipped with openSUSE 13.1
In my test setup everything works with DIGEST-MD5 but not with PLAIN or LOGIN (clear-text userPassword value for testing). The log shows that the SASL username gets mapped by authz-regexp to the correct LDAP user entry:
52f60408 <==slap_sasl2dn: Converted SASL name to uid=user,ou=dept,o=example 52f60408 slap_sasl_getdn: dn:id converted to uid=user,ou=dept,o=example
But SASL does not use "pwcheck_method: slapd" for mechs PLAIN/LOGIN but works with DIGEST-MD5:
$ ldapwhoami -H ldapi:/// -Y DIGEST-MD5 -U user -w secret SASL/DIGEST-MD5 authentication started SASL username: user SASL SSF: 128 SASL data security layer installed. dn:uid=user,ou=dept,o=example $ ldapwhoami -H ldapi:/// -Y LOGIN -U user -w secret SASL/LOGIN authentication started ldap_sasl_interactive_bind_s: Authentication method not supported (7) additional info: SASL(-4): no mechanism available: checkpass failed $ ldapwhoami -H ldapi:/// -Y PLAIN -U user -w secret SASL/PLAIN authentication started ldap_sasl_interactive_bind_s: Authentication method not supported (7) additional info: SASL(-4): no mechanism available: Password verification failed
The trace shows for PLAIN or LOGIN (running slapd -d config,stats,stats2,acl,args,trace):
SASL [conn=1002] Error: unknown password verifier(s) slapd
My /usr/lib64/sasl.conf contains: ---------------------------- snip ---------------------------- pwcheck_method: slapd mech_list: plain login digest-md5 external ---------------------------- snip ---------------------------- I've checked that this is the right file by setting "pwcheck_method: foobar" which appears in the logs then.
Wrong configuration file. You should configure slapd in /etc/sasl2/slapd.conf mech_list: gssapi digest-md5 cram-md5 external plain login auxprop_plugin: slapd ldapwhoami -Y LOGIN -U mailadmin -w secret -H ldapi:/// SASL/LOGIN authentication started SASL username: mailadmin SASL SSF: 0 dn:cn=mailadmin,o=avci,c=de
-Dieter
Dieter Klünter wrote:
Am Sat, 08 Feb 2014 11:45:52 +0100 schrieb Michael Ströder michael@stroeder.com:
My /usr/lib64/sasl.conf contains: ---------------------------- snip ---------------------------- pwcheck_method: slapd mech_list: plain login digest-md5 external ---------------------------- snip ---------------------------- I've checked that this is the right file by setting "pwcheck_method: foobar" which appears in the logs then.
Wrong configuration file. You should configure slapd in /etc/sasl2/slapd.conf
As said: At least the file /usr/lib64/sasl.conf has an effect because I can see an error message with "foobar" if I set "pwcheck_method: foobar" in there.
mech_list: gssapi digest-md5 cram-md5 external plain login auxprop_plugin: slapd ldapwhoami -Y LOGIN -U mailadmin -w secret -H ldapi:/// SASL/LOGIN authentication started SASL username: mailadmin SASL SSF: 0 dn:cn=mailadmin,o=avci,c=de
Yes, got that working in the meantime. But unfortunately this only works with clear-text userPassword values. That's definitely not what I want.
Ciao, Michael.
Am Sat, 08 Feb 2014 23:18:22 +0100 schrieb Michael Ströder michael@stroeder.com:
Dieter Klünter wrote:
Am Sat, 08 Feb 2014 11:45:52 +0100 schrieb Michael Ströder michael@stroeder.com:
[...]
Yes, got that working in the meantime. But unfortunately this only works with clear-text userPassword values. That's definitely not what I want.
Than you have to rely on an external password store, i.e. kerberos. But that all is security by obscurity if you don't harden the network and services.
-Dieter
On Sun, 9 Feb 2014, Dieter Klünter wrote:
Am Sat, 08 Feb 2014 23:18:22 +0100 schrieb Michael Ströder michael@stroeder.com:
Dieter Klünter wrote:
Am Sat, 08 Feb 2014 11:45:52 +0100 schrieb Michael Ströder michael@stroeder.com:
[...]
Yes, got that working in the meantime. But unfortunately this only works with clear-text userPassword values. That's definitely not what I want.
Than you have to rely on an external password store, i.e. kerberos. But that all is security by obscurity if you don't harden the network and services.
At least at one time, cyrus-sasl supported the ability to request from the auxprop mechanism alternate types of data that would be sufficient for doing the server-side of the SASL exchange. For example, with CRAM-MD5 it could store the HMAC-MD5 context keyed with the user password (c.f. RFC2195), which is sufficient for calculating the expected digest. The cyrus-sasl code would request both that form and the cleartext and then use whichever it got.
Of course, for both cram-md5 and digest-md5, the "prehash form" was sufficent to authenticate using those as the client, so the security gain was negligible: yeah, you didn't have the 'real' cleartext form, but you could still login as the user. Add on the complexity of keeping that data up to date and the benefit of this seems complexity seems hard to justify.
I believe that that property of the server authenticator being sufficent to authenticate as the client is *not* true of some newer mechs: iirc, SRP uses some form of zero-knowledge proof such that the server doesn't need to store a password-equivalent. That might also be the case with the SCRAM-* family.
Still, there are at least two problems with that as a solution: 1) can you really require the SASL clients in your setup to use SRP? (if it's that easy to require new mechanisms, I would expect more use of Kerberos!) 2) does the openldap 'slapd' auxprop support lookup of those alternate data types as other attributes? If so, what/where's the schema for them?
Philip Guenther
Philip Guenther wrote:
On Sun, 9 Feb 2014, Dieter Klünter wrote:
Am Sat, 08 Feb 2014 23:18:22 +0100 schrieb Michael Ströder michael@stroeder.com:
Dieter Klünter wrote:
Am Sat, 08 Feb 2014 11:45:52 +0100 schrieb Michael Ströder michael@stroeder.com:
[...]
Yes, got that working in the meantime. But unfortunately this only works with clear-text userPassword values. That's definitely not what I want.
Than you have to rely on an external password store, i.e. kerberos. But that all is security by obscurity if you don't harden the network and services.
At least at one time, cyrus-sasl supported the ability to request from the auxprop mechanism alternate types of data that would be sufficient for doing the server-side of the SASL exchange. For example, with CRAM-MD5 it could store the HMAC-MD5 context keyed with the user password (c.f. RFC2195), which is sufficient for calculating the expected digest. The cyrus-sasl code would request both that form and the cleartext and then use whichever it got.
Of course, for both cram-md5 and digest-md5, the "prehash form" was sufficent to authenticate using those as the client, so the security gain was negligible: yeah, you didn't have the 'real' cleartext form, but you could still login as the user. Add on the complexity of keeping that data up to date and the benefit of this seems complexity seems hard to justify.
I believe that that property of the server authenticator being sufficent to authenticate as the client is *not* true of some newer mechs: iirc, SRP uses some form of zero-knowledge proof such that the server doesn't need to store a password-equivalent. That might also be the case with the SCRAM-* family.
Still, there are at least two problems with that as a solution:
- can you really require the SASL clients in your setup to use SRP? (if it's that easy to require new mechanisms, I would expect more use of Kerberos!)
- does the openldap 'slapd' auxprop support lookup of those alternate data types as other attributes? If so, what/where's the schema for them?
The slapd auxprop simply looks up whatever attribute names SASL passed in. If there's no schema definition for these attributes, naturally those lookups will fail but the failure is ignored, the auxprop just returns as much as it knows about.
openldap-technical@openldap.org
-
Dan White -
Dieter Klünter -
Howard Chu -
Michael Ströder -
Philip Guenther