Re: Bind using a user other than organizationalRole user

[Marcelo de Moraes Serpa <celoserpa@gmail.com>]

Hello all,

Thank you for the insights. 
> > In general: if you haven't explicitly defined an ACL, OpenLDAP is
> > configured to allow anonymous reads -- this is *not* sufficient to auth.
> > You will want to allow anonymous auth to the appropriate DNs.
Yeah, I figured that out. I probably created a situation where:
 1) I tried authenticating without the proper ACL, it failed; 
 2) Entered trial and error mode, tried changing userPassword to {CLEARTEXT}secret_12345
 3) Didn't work either;
 4) Put the: "access to * by * read" ACL, restarted server.
 5) Tried authenticating with secret_12345, didn't work
 6) Too much time spent, couldn't spend more time on the issue. Tried just converting secret_12345 to SHA-1 and updating the value of userPassword
 7) Worked!
 8) Could finally relax and get out to get some fresh air ;)

So, the point is, I could get it to work. This is not to say I wouldn't like to know what happened, it is on my list, I might go through the process again next weekend and document my findings, but I think you guys already said what was to be said about the issue.

Cheers and peace!

Marcelo.

2010/4/7 Michael Ströder <michael@stroeder.com>

Marcelo de Moraes Serpa wrote:

> Hi Dieter, thanks for the reply.
>
> Yeah, the folks @ #openladp were kind enough to help me to debug this
> issue. It turned out that it was a simple detail (as mostly always :))
> -- When I created the ldif, I've put the password in clear text,
> however, I didn't do anything to tell openldap that it was actually
> cleartext nor I knew I had to. The whole time I though it had to do with
> ACLs (OpenLDAP denying read-access to userPassword), but the problem was
> that OpenLDAP was trying to authenticate using SHA-1, and the password
> was stored as clear text.
>
> The solution? Store the password as a SHA-1 hash. Nobody would want to
> store password as clear-text anyway.

There's nothing wrong with storing a clear-text password like

userPassword: secret_12345

in the directory entry. In fact you have to when e.g. using SASL/DIGEST-MD5
bind with in-directory passwords.

When processing a simple bind slapd looks whether a password is stored in
hashed form by looking at a magic prefix like {SSHA}. If that prefix is not
there it is assumed that the password is stored in clear and this gets compared.

> So, issue solved!

Hmm, I think you mixed up something.

Ciao, Michael.