OK, got that.

Now I am trying a different SASL configuration, and I have these mechanisms available:

ldapsearch -h localhost:9999 -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:9999 -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 dwhite@olp.net 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:9999 1>& slapd.log 2>&1 &

Available SASL mechanism

...

ldapsearch -h localhost:9999 -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:9999 -x -w secret -D cn=Manager,dc=my-domain,dc=com -f ./new_user.ldif

...

ldapsearch -h localhost:9999 -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:9999 -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:9999 -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=

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:9999 -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:9999 -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 dieter@dkluenter.de wrote:

"Zohar Lev Shani" levshani5252@gmail.com writes:

...

OK, got that.

Now I am trying a different SASL configuration, and I have these mechanisms available:

...

ldapsearch -h localhost:9999 -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:9999 -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

Dieter Kluenter wrote:

"Zohar Lev Shani" levshani5252@gmail.com 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:9999 -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.

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