[Date Prev][Date Next]
Re: OpenLDAP as a SASL backend
Dieter Kluenter wrote:
"Zohar Lev Shani" <email@example.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
Using cleartext password solves the problem but this is not what I am trying
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/