On 11/5/07, Howard Chu <hyc@symas.com> wrote:

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/