Re: OpenLDAP as a SASL backend

Dieter Kluenter wrote: > "Zohar Lev Shani" <levshani5252(a)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/