2:45 a.m.
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.
4:11 a.m.
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
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5:27 a.m.
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.
11:56 a.m.
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.
--
Dan White
1:15 p.m.
Hallo Michael,
Am Sat, 08 Feb 2014 11:45:52 +0100
schrieb Michael Ströder <michael(a)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 | Systemberatung
http://dkluenter.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
2:18 p.m.
Dieter Klünter wrote:
Am Sat, 08 Feb 2014 11:45:52 +0100
schrieb Michael Ströder <michael(a)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.
12:55 a.m.
Am Sat, 08 Feb 2014 23:18:22 +0100
schrieb Michael Ströder <michael(a)stroeder.com>:
Dieter Klünter wrote:
> Am Sat, 08 Feb 2014 11:45:52 +0100
> schrieb Michael Ströder <michael(a)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
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"
2:52 a.m.
On Sun, 9 Feb 2014, Dieter Klünter wrote:
Am Sat, 08 Feb 2014 23:18:22 +0100
schrieb Michael Ströder <michael(a)stroeder.com>:
> Dieter Klünter wrote:
> > Am Sat, 08 Feb 2014 11:45:52 +0100
> > schrieb Michael Ströder <michael(a)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
6:23 a.m.
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(a)stroeder.com>:
>
>> Dieter Klünter wrote:
>>> Am Sat, 08 Feb 2014 11:45:52 +0100
>>> schrieb Michael Ströder <michael(a)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?
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
3583
days inactive
3584
days old
openldap-technical@openldap.org
8 comments
5 participants
participants (5)
-
Dan White -
Dieter Klünter -
Howard Chu -
Michael Ströder -
Philip Guenther