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: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/ >
