Re: OpenLDAP as a SASL backend
On Monday 05 November 2007 13:20:04 Zohar Lev Shani wrote: > I understand now why I cannot put hashed userPassword when I use SASL. But, > does it mean that the ONLY place where I can use hashed passwords for > authentication is the rootpw directive in slapd.conf, or, there are more > sensible use cases where it can be used? Uh, well, if you want to use SASL mechanisms that require a shared secret, obviously: no. If you want to use simple binds, then you can use a hashed userPassword. If you want to use other SASL mechanisms that support encrypted keys, mutual 3rd-party authentication - then you're not going to use userPassword at all ... Regards, Buchan
Re: OpenLDAP as a SASL backend
"Zohar Lev Shani" <[EMAIL PROTECTED]> writes: > I understand now why I cannot put hashed userPassword when I use SASL. But, > does it mean that the ONLY place where I can use hashed passwords for > authentication is the rootpw directive in slapd.conf, or, there are more > sensible use cases where it can be used? > > On 11/5/07, Howard Chu <[EMAIL PROTECTED]> wrote: > Dieter Kluenter wrote: > > "Zohar Lev Shani" < [EMAIL PROTECTED] > writes: [...] You may use hashed passwords as userPassword attribute value for simple binds. Why do you want hashed passwords at all? I think this is just security by obscurity. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6
Re: OpenLDAP as a SASL backend
I understand now why I cannot put hashed userPassword when I use SASL. But, does it mean that the ONLY place where I can use hashed passwords for authentication is the rootpw directive in slapd.conf, or, there are more sensible use cases where it can be used? On 11/5/07, Howard Chu <[EMAIL PROTECTED]> wrote: > > Dieter Kluenter wrote: > > "Zohar Lev Shani" <[EMAIL PROTECTED] > writes: > > > >> I had set up a secured TLS with all the certificates and keys needed. > But > >> still, I cannot login using SASL and PLAIN/LOGIN mechanisms over TLS. > The user > >> in the example has the userPassword hashed in MD5. See errors below: > > SASL/LOGIN was deprecated long ago and should never be used. > > >>> ldapsearch -h localhost: -Y PLAIN -w pass1 -U user1 -b > dc=my-domain,dc= > >> com -s base -ZZ > >> SASL/PLAIN authentication started > >> ldap_sasl_interactive_bind_s: Invalid credentials (49) > >> additional info: SASL(-13): user not found: Password > verification > >> failed > > >> Using cleartext password solves the problem but this is not what I am > trying > >> to do. > >> Just a reminder of what I am trying to achieve: In the database I want > the > >> userPassword field to be hashed and the bind authentication will be > against it > >> using the authz-regexp directive in slapd.conf. Using DIGEST-MD5 SASL > doesn't > >> help here because the userPassword needs to be in cleartext in the > database. > > > Any sasl mechanism, except external, requires cleartext password. > > SASL mechanisms that use a simple secret anyway. GSSAPI doesn't. > > You really have to think about what you're trying to secure. It's fair to > say > that you can't allow cleartext passwords in the database for one policy or > another, but none of these shared-secret authentication mechanisms will > work > without the password or a plaintext-equivalent. (E.g., DIGEST-MD5 can also > work with a pre-hashed password stored in the cmusaslsecretDIGEST-MD5 > attribute.) If your goal is simply keeping human-readable passwords out of > the > database, this will work for you. If your goal is preventing any usable > secrets from being stored in the database, then you're out of luck. > > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sunhttp://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ >
Re: OpenLDAP as a SASL backend
Dieter Kluenter wrote: "Zohar Lev Shani" <[EMAIL PROTECTED]> writes: I had set up a secured TLS with all the certificates and keys needed. But still, I cannot login using SASL and PLAIN/LOGIN mechanisms over TLS. The user in the example has the userPassword hashed in MD5. See errors below: SASL/LOGIN was deprecated long ago and should never be used. ldapsearch -h localhost: -Y PLAIN -w pass1 -U user1 -b dc=my-domain,dc= com -s base -ZZ SASL/PLAIN authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: Password verification failed Using cleartext password solves the problem but this is not what I am trying to do. Just a reminder of what I am trying to achieve: In the database I want the userPassword field to be hashed and the bind authentication will be against it using the authz-regexp directive in slapd.conf. Using DIGEST-MD5 SASL doesn't help here because the userPassword needs to be in cleartext in the database. Any sasl mechanism, except external, requires cleartext password. SASL mechanisms that use a simple secret anyway. GSSAPI doesn't. You really have to think about what you're trying to secure. It's fair to say that you can't allow cleartext passwords in the database for one policy or another, but none of these shared-secret authentication mechanisms will work without the password or a plaintext-equivalent. (E.g., DIGEST-MD5 can also work with a pre-hashed password stored in the cmusaslsecretDIGEST-MD5 attribute.) If your goal is simply keeping human-readable passwords out of the database, this will work for you. If your goal is preventing any usable secrets from being stored in the database, then you're out of luck. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenLDAP as a SASL backend
"Zohar Lev Shani" <[EMAIL PROTECTED]> writes: > I had set up a secured TLS with all the certificates and keys needed. But > still, I cannot login using SASL and PLAIN/LOGIN mechanisms over TLS. The user > in the example has the userPassword hashed in MD5. See errors below: > >>ldapsearch -h localhost: -Y PLAIN -w pass1 -U user1 -b dc=my-domain,dc= > com -s base -ZZ > SASL/PLAIN authentication started > ldap_sasl_interactive_bind_s: Invalid credentials (49) > additional info: SASL(-13): user not found: Password verification > failed > >>ldapsearch -h localhost: -Y LOGIN -w pass1 -U user1 -b dc=my-domain,dc= > com -s base -ZZ > SASL/LOGIN authentication started > ldap_sasl_interactive_bind_s: Invalid credentials (49) > additional info: SASL(-13): user not found: checkpass failed > > Using cleartext password solves the problem but this is not what I am trying > to do. > Just a reminder of what I am trying to achieve: In the database I want the > userPassword field to be hashed and the bind authentication will be against it > using the authz-regexp directive in slapd.conf. Using DIGEST-MD5 SASL doesn't > help here because the userPassword needs to be in cleartext in the database. Any sasl mechanism, except external, requires cleartext password. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6
Re: OpenLDAP as a SASL backend
I had set up a secured TLS with all the certificates and keys needed. But still, I cannot login using SASL and PLAIN/LOGIN mechanisms over TLS. The user in the example has the userPassword hashed in MD5. See errors below: >ldapsearch -h localhost: -Y PLAIN -w pass1 -U user1 -b dc=my-domain,dc=com -s base -ZZ SASL/PLAIN authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: Password verification failed >ldapsearch -h localhost: -Y LOGIN -w pass1 -U user1 -b dc=my-domain,dc=com -s base -ZZ SASL/LOGIN authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: checkpass failed Using cleartext password solves the problem but this is not what I am trying to do. Just a reminder of what I am trying to achieve: In the database I want the userPassword field to be hashed and the bind authentication will be against it using the authz-regexp directive in slapd.conf. Using DIGEST-MD5 SASL doesn't help here because the userPassword needs to be in cleartext in the database. Yet again, any help will be appreciated. Zohar On 10/23/07, Dieter Kluenter <[EMAIL PROTECTED]> wrote: > > "Zohar Lev Shani" <[EMAIL PROTECTED]> writes: > > > OK, got that. > > > > Now I am trying a different SASL configuration, and I have these > > mechanisms available: > > > >> ldapsearch -h localhost: -x -b '' supportedSASLMechanisms -s base > -LLL > > dn: > > supportedSASLMechanisms: LOGIN > > supportedSASLMechanisms: PLAIN > > > > With the same data, I tried running ldapsearch with SASL and got that > > there are no SASL mechanisms available. > > > >> ldapsearch -h localhost: -Y PLAIN -U user1 -w pass1 -LLL -b > cn=user1,cn=users,dc=my-domain,dc=com > > ldap_sasl_interactive_bind_s: Unknown authentication method (-6) > > additional info: SASL(-4): no mechanism available: No worthy > mechs found > > > > Same goes for '-Y LOGIN'. > > > > What am I missing here? > > OpenLDAP only supports PLAIN and LOGIN if data transport is secured > that is either by TLS or local pipe. Install sasl libdigestmd5 and > libcrammd5 to provide shared secret security. > > -Dieter > > -- > Dieter Klünter | Systemberatung > http://www.dkluenter.de > GPG Key ID:8EF7B6C6 >
Re: OpenLDAP as a SASL backend
"Zohar Lev Shani" <[EMAIL PROTECTED]> writes: > OK, got that. > > Now I am trying a different SASL configuration, and I have these > mechanisms available: > >> ldapsearch -h localhost: -x -b '' supportedSASLMechanisms -s base -LLL > dn: > supportedSASLMechanisms: LOGIN > supportedSASLMechanisms: PLAIN > > With the same data, I tried running ldapsearch with SASL and got that > there are no SASL mechanisms available. > >> ldapsearch -h localhost: -Y PLAIN -U user1 -w pass1 -LLL -b >> cn=user1,cn=users,dc=my-domain,dc=com > ldap_sasl_interactive_bind_s: Unknown authentication method (-6) > additional info: SASL(-4): no mechanism available: No worthy mechs > found > > Same goes for '-Y LOGIN'. > > What am I missing here? OpenLDAP only supports PLAIN and LOGIN if data transport is secured that is either by TLS or local pipe. Install sasl libdigestmd5 and libcrammd5 to provide shared secret security. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6
Re: OpenLDAP as a SASL backend
OK, got that.
Now I am trying a different SASL configuration, and I have these
mechanisms available:
> ldapsearch -h localhost: -x -b '' supportedSASLMechanisms -s base -LLL
dn:
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: PLAIN
With the same data, I tried running ldapsearch with SASL and got that
there are no SASL mechanisms available.
> ldapsearch -h localhost: -Y PLAIN -U user1 -w pass1 -LLL -b
> cn=user1,cn=users,dc=my-domain,dc=com
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
additional info: SASL(-4): no mechanism available: No worthy mechs found
Same goes for '-Y LOGIN'.
What am I missing here?
Thanks in advance
Zohar
On 10/11/07, Dan White <[EMAIL PROTECTED]> wrote:
> Zohar,
>
> See:
>
> http://www.openldap.org/doc/admin23/sasl.html
>
> Specifically section 11.2.3 for a discussion of DIGEST-MD5.
>
> If using DIGEST-MD5, your password will be treated as a shared
> secret and will not be transmitted over the wire. Also, if
> configured correctly (data security layer), the remaining portion
> of your connection will be encrypted.
>
> - Dan White
>
> Zohar Lev Shani wrote:
> > Hello list
> >
> > I am trying to use OpenLDAP also as a repository of the user and
> > password to the SASL mechanism.
> > The problem I am facing is that it only works if the userPassword is
> > kept in clear text and not in a hashed form. I would like to use the
> > hashed form because my application has a proprietary backend where the
> > data goes over the wire and for that I need userPassword attribute to
> > be not in clear text.
> >
> > Below is what I tried to do, based on OpenLDAP 2.3.24 running on RH4
> > U3 (Nahant).
> >
> > Any help will be appreciated.
> >
> > Zohar
> >
> >
> >> ./configure --prefix=`pwd`
> >
> > I added to the default slapd.conf with this entry
> > authz-regexp "uid=([^,]*)" "cn=$1,cn=users,dc=my-domain,dc=com"
> >
> > The run command
> >> ./slapd -f slapd.conf -d -1 -h ldap://localhost: 1>& slapd.log 2>&1 &
> >
> > Available SASL mechanism
> >> ldapsearch -h localhost: -x -b '' supportedSASLMechanisms -s base -LLL
> > dn:
> > supportedSASLMechanisms: DIGEST-MD5
> > supportedSASLMechanisms: CRAM-MD5
> > supportedSASLMechanisms: GSSAPI
> > supportedSASLMechanisms: NTLM
> >
> > Data I am going to add
> >> cat ./new_user.ldif
> > dn: dc=my-domain,dc=com
> > objectclass: dcObject
> > objectclass: organization
> > o: my-org
> > dc: my-domain
> >
> > dn: cn=Manager,dc=my-domain,dc=com
> > objectclass: organizationalRole
> > cn: Manager
> >
> > dn: cn=users,dc=my-domain,dc=com
> > objectclass: organizationalRole
> > cn: users
> >
> > dn: cn=user1,cn=users,dc=my-domain,dc=com
> > objectclass: organizationalRole
> > objectclass: simpleSecurityObject
> > cn: user1
> > userPassword: {MD5}pyLGPbjshiWvbPccuMLZOQ==
> > #password: pass1
> >
> > dn: cn=user3,cn=users,dc=my-domain,dc=com
> > objectclass: organizationalRole
> > objectclass: simpleSecurityObject
> > cn: user3
> > userPassword: {CLEARTEXT}pass3
> >
> >> ldapadd -h localhost: -x -w secret -D cn=Manager,dc=my-domain,dc=com
> >> -f ./new_user.ldif
> >
> >> ldapsearch -h localhost: -x -LLL -b
> >> cn=user1,cn=users,dc=my-domain,dc=com
> > dn: cn=user1,cn=users,dc=my-domain,dc=com
> > objectClass: organizationalRole
> > objectClass: simpleSecurityObject
> > cn: user1
> > userPassword:: e01ENX1weUxHUGJqc2hpV3ZiUGNjdU1MWk9RPT0=
> >
> >> ldapsearch -h localhost: -Y DIGEST-MD5 -U user1 -w pass1 -LLL -b
> >> cn=user1,cn=users,dc=my-domain,dc=com
> > SASL/DIGEST-MD5 authentication started
> > ldap_sasl_interactive_bind_s: Invalid credentials (49)
> > additional info: SASL(-13): user not found: no secret in database
> >
> >> ldapsearch -h localhost: -Y DIGEST-MD5 -U user3 -w pass3 -LLL -b
> >> cn=user1,cn=users,dc=my-domain,dc=com
> > SASL/DIGEST-MD5 authentication started
> > SASL username: user3
> > SASL SSF: 128
> > SASL installing layers
> > dn: cn=user1,cn=users,dc=my-domain,dc=com
> > objectClass: organizationalRole
> > objectClass: simpleSecurityObject
> > cn: user1
> > userPassword:: e01ENX1weUxHUGJqc2hpV3ZiUGNjdU1MWk9RPT0=
>
>
Re: OpenLDAP as a SASL backend
Zohar,
See:
http://www.openldap.org/doc/admin23/sasl.html
Specifically section 11.2.3 for a discussion of DIGEST-MD5.
If using DIGEST-MD5, your password will be treated as a shared
secret and will not be transmitted over the wire. Also, if
configured correctly (data security layer), the remaining portion
of your connection will be encrypted.
- Dan White
Zohar Lev Shani wrote:
Hello list
I am trying to use OpenLDAP also as a repository of the user and
password to the SASL mechanism.
The problem I am facing is that it only works if the userPassword is
kept in clear text and not in a hashed form. I would like to use the
hashed form because my application has a proprietary backend where the
data goes over the wire and for that I need userPassword attribute to
be not in clear text.
Below is what I tried to do, based on OpenLDAP 2.3.24 running on RH4
U3 (Nahant).
Any help will be appreciated.
Zohar
./configure --prefix=`pwd`
I added to the default slapd.conf with this entry
authz-regexp "uid=([^,]*)" "cn=$1,cn=users,dc=my-domain,dc=com"
The run command
./slapd -f slapd.conf -d -1 -h ldap://localhost: 1>& slapd.log 2>&1 &
Available SASL mechanism
ldapsearch -h localhost: -x -b '' supportedSASLMechanisms -s base -LLL
dn:
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: NTLM
Data I am going to add
cat ./new_user.ldif
dn: dc=my-domain,dc=com
objectclass: dcObject
objectclass: organization
o: my-org
dc: my-domain
dn: cn=Manager,dc=my-domain,dc=com
objectclass: organizationalRole
cn: Manager
dn: cn=users,dc=my-domain,dc=com
objectclass: organizationalRole
cn: users
dn: cn=user1,cn=users,dc=my-domain,dc=com
objectclass: organizationalRole
objectclass: simpleSecurityObject
cn: user1
userPassword: {MD5}pyLGPbjshiWvbPccuMLZOQ==
#password: pass1
dn: cn=user3,cn=users,dc=my-domain,dc=com
objectclass: organizationalRole
objectclass: simpleSecurityObject
cn: user3
userPassword: {CLEARTEXT}pass3
ldapadd -h localhost: -x -w secret -D cn=Manager,dc=my-domain,dc=com -f
./new_user.ldif
ldapsearch -h localhost: -x -LLL -b cn=user1,cn=users,dc=my-domain,dc=com
dn: cn=user1,cn=users,dc=my-domain,dc=com
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: user1
userPassword:: e01ENX1weUxHUGJqc2hpV3ZiUGNjdU1MWk9RPT0=
ldapsearch -h localhost: -Y DIGEST-MD5 -U user1 -w pass1 -LLL -b
cn=user1,cn=users,dc=my-domain,dc=com
SASL/DIGEST-MD5 authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-13): user not found: no secret in database
ldapsearch -h localhost: -Y DIGEST-MD5 -U user3 -w pass3 -LLL -b
cn=user1,cn=users,dc=my-domain,dc=com
SASL/DIGEST-MD5 authentication started
SASL username: user3
SASL SSF: 128
SASL installing layers
dn: cn=user1,cn=users,dc=my-domain,dc=com
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: user1
userPassword:: e01ENX1weUxHUGJqc2hpV3ZiUGNjdU1MWk9RPT0=
