[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenLDAP as a SASL backend

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.

--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP     http://www.openldap.org/project/