Bind using a user other than organizationalRole user

[Marcelo de Moraes Serpa]

Hello list,

I have a local OpenLDAP server with a couple of users. I'm using it for
development purposes, here's the ldif:

#Top level - the organization
dn: dc=site, dc=com
dc: site
description: OneLogin LLC
objectClass: dcObject
objectClass: organization
o: OneLogin LLC

#Top level - manager
dn: cn=Manager, dc=site, dc=com
objectClass: organizationalRole
cn: Manager

#Second level - organizational units
dn: ou=people, dc=site, dc=com
ou: people
description: All people in the organization
objectClass: organizationalunit

dn: ou=groups, dc=site, dc=com
ou: groups
description: All groups in the organization
objectClass: organizationalunit

#Third level - people
dn: uid=celoserpa, ou=people, dc=site, dc=com
objectclass: pilotPerson
objectclass: uidObject
uid: celoserpa
cn: Marcelo de Moraes Serpa
sn: de Moraes Serpa
userPassword: secret_12345
mail: ***@site.com

So far, so good. I can bind with "cn=Manager,dc=site,dc=com" and the
12345678 password (the local server password, setup on slapd.conf).

However, I would like to bind with any user in under the people OU. In this
case, I'd like to bind with:
dn: uid=celoserpa, ou=people, dc=site, dc=com
userPassword: secret_12345

But I'm getting a (49) - Invalid Credentials error everytime. I have tried
through CLI tools (such as ldapadd, ldapwhoami, etc) and also ruby/ldap. The
bind with these credentials fails with a invalid credentials error.

I was suspecting that maybe OpenLDAP doesn't compare against userPassword?
Or maybe some ACL configuration I am missing that is somehow affecting the
read access to userPassword for the specific DN.

I'm really lost here, any suggestion appreciated!

Cheers,

Marcelo.

[Dieter Kluenter]

Am Tue, 6 Apr 2010 13:28:27 -0500

Post by Marcelo de Moraes Serpa
Hello list,
I have a local OpenLDAP server with a couple of users. I'm using it
#Top level - the organization
dn: dc=site, dc=com
dc: site
description: OneLogin LLC
objectClass: dcObject
objectClass: organization
o: OneLogin LLC
#Top level - manager
dn: cn=Manager, dc=site, dc=com
objectClass: organizationalRole
cn: Manager
#Second level - organizational units
dn: ou=people, dc=site, dc=com
ou: people
description: All people in the organization
objectClass: organizationalunit
dn: ou=groups, dc=site, dc=com
ou: groups
description: All groups in the organization
objectClass: organizationalunit
#Third level - people
dn: uid=celoserpa, ou=people, dc=site, dc=com
objectclass: pilotPerson
objectclass: uidObject
uid: celoserpa
cn: Marcelo de Moraes Serpa
sn: de Moraes Serpa
userPassword: secret_12345
So far, so good. I can bind with "cn=Manager,dc=site,dc=com" and the
12345678 password (the local server password, setup on slapd.conf).
However, I would like to bind with any user in under the people OU.
dn: uid=celoserpa, ou=people, dc=site, dc=com
userPassword: secret_12345
But I'm getting a (49) - Invalid Credentials error everytime. I have
tried through CLI tools (such as ldapadd, ldapwhoami, etc) and also
ruby/ldap. The bind with these credentials fails with a invalid
credentials error.
I was suspecting that maybe OpenLDAP doesn't compare against
userPassword? Or maybe some ACL configuration I am missing that is
somehow affecting the read access to userPassword for the specific DN.
I'm really lost here, any suggestion appreciated!

You may run slapd in debugging mode, that is slapd(8) -dacl

-Dieter

[Marcelo de Moraes Serpa]

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.

So, issue solved!

Cheers,

Marcelo.

Post by Dieter Kluenter
Am Tue, 6 Apr 2010 13:28:27 -0500

Post by Marcelo de Moraes Serpa
Hello list,
I have a local OpenLDAP server with a couple of users. I'm using it
#Top level - the organization
dn: dc=site, dc=com
dc: site
description: OneLogin LLC
objectClass: dcObject
objectClass: organization
o: OneLogin LLC
#Top level - manager
dn: cn=Manager, dc=site, dc=com
objectClass: organizationalRole
cn: Manager
#Second level - organizational units
dn: ou=people, dc=site, dc=com
ou: people
description: All people in the organization
objectClass: organizationalunit
dn: ou=groups, dc=site, dc=com
ou: groups
description: All groups in the organization
objectClass: organizationalunit
#Third level - people
dn: uid=celoserpa, ou=people, dc=site, dc=com
objectclass: pilotPerson
objectclass: uidObject
uid: celoserpa
cn: Marcelo de Moraes Serpa
sn: de Moraes Serpa
userPassword: secret_12345
So far, so good. I can bind with "cn=Manager,dc=site,dc=com" and the
12345678 password (the local server password, setup on slapd.conf).
However, I would like to bind with any user in under the people OU.
dn: uid=celoserpa, ou=people, dc=site, dc=com
userPassword: secret_12345
But I'm getting a (49) - Invalid Credentials error everytime. I have
tried through CLI tools (such as ldapadd, ldapwhoami, etc) and also
ruby/ldap. The bind with these credentials fails with a invalid
credentials error.
I was suspecting that maybe OpenLDAP doesn't compare against
userPassword? Or maybe some ACL configuration I am missing that is
somehow affecting the read access to userPassword for the specific DN.
I'm really lost here, any suggestion appreciated!

You may run slapd in debugging mode, that is slapd(8) -dacl
-Dieter
--
Dieter Klünter | Systemberatung
sip: +49.40.20932173
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6

[Michael Ströder]

Post by Marcelo de Moraes Serpa
Hi Dieter, thanks for the reply.
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.

Post by Marcelo de Moraes Serpa
So, issue solved!

Hmm, I think you mixed up something.

Ciao, Michael.

[Marcelo de Moraes Serpa]

Hello all,

Thank you for the insights.

In general: if you haven't explicitly defined an ACL, OpenLDAP is

Post by Owen Marshall
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.

Post by Owen Marshall

Post by Marcelo de Moraes Serpa
Hi Dieter, thanks for the reply.
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.

Post by Marcelo de Moraes Serpa
So, issue solved!

Hmm, I think you mixed up something.
Ciao, Michael.

[Buchan Milne]

Post by Marcelo de Moraes Serpa
Hello list,
I have a local OpenLDAP server with a couple of users. I'm using it for
#Top level - the organization
dn: dc=site, dc=com
dc: site
description: OneLogin LLC
objectClass: dcObject
objectClass: organization
o: OneLogin LLC
#Top level - manager
dn: cn=Manager, dc=site, dc=com
objectClass: organizationalRole
cn: Manager
#Second level - organizational units
dn: ou=people, dc=site, dc=com
ou: people
description: All people in the organization
objectClass: organizationalunit
dn: ou=groups, dc=site, dc=com
ou: groups
description: All groups in the organization
objectClass: organizationalunit
#Third level - people
dn: uid=celoserpa, ou=people, dc=site, dc=com
objectclass: pilotPerson
objectclass: uidObject
uid: celoserpa
cn: Marcelo de Moraes Serpa
sn: de Moraes Serpa
userPassword: secret_12345
So far, so good. I can bind with "cn=Manager,dc=site,dc=com" and the
12345678 password (the local server password, setup on slapd.conf).

Hashed or clear?

Post by Marcelo de Moraes Serpa
However, I would like to bind with any user in under the people OU. In this
dn: uid=celoserpa, ou=people, dc=site, dc=com
userPassword: secret_12345
But I'm getting a (49) - Invalid Credentials error everytime. I have tried
through CLI tools (such as ldapadd, ldapwhoami, etc) and also ruby/ldap.

Can you supply your ldapwhoami commandline, and the exact error message.

Post by Marcelo de Moraes Serpa
The bind with these credentials fails with a invalid credentials error.
I was suspecting that maybe OpenLDAP doesn't compare against userPassword?

No. It could be that your build doesn't allow cleartext values for
userPassword, you could try with a hashed value (created with slappasswd), or
verify that your build allows cleartext (configure option:
--enable-cleartext
).

Post by Marcelo de Moraes Serpa
Or maybe some ACL configuration I am missing that is somehow affecting the
read access to userPassword for the specific DN.

If it is not that your build doesn't allow cleartext, then it's probably ACLs,
but since you didn't include your ACL configuration this can't be answered
definitively. And, it is actually "auth" access that is sufficient.

Post by Marcelo de Moraes Serpa
I'm really lost here, any suggestion appreciated!

Can't provide more help without more information.

Regards,
Buchan

[Bjørn Ruberg]

Post by Marcelo de Moraes Serpa
Hello list,
I have a local OpenLDAP server with a couple of users. I'm using it

[...]

Post by Marcelo de Moraes Serpa
So far, so good. I can bind with "cn=Manager,dc=site,dc=com" and the
12345678 password (the local server password, setup on slapd.conf).
However, I would like to bind with any user in under the people OU. In
dn: uid=celoserpa, ou=people, dc=site, dc=com
userPassword: secret_12345

And you are completely sure that this entry exists in the LDAP database,
and that the userPassword attribute has a value? Use slapcat to see
what's in the backend database.

Post by Marcelo de Moraes Serpa
But I'm getting a (49) - Invalid Credentials error everytime. I have
tried through CLI tools (such as ldapadd, ldapwhoami, etc) and also
ruby/ldap. The bind with these credentials fails with a invalid
credentials error.

Please show the list how you use those tools.

Post by Marcelo de Moraes Serpa
I was suspecting that maybe OpenLDAP doesn't compare against userPassword?

I don't think that's very likely...

Post by Marcelo de Moraes Serpa
Or maybe some ACL configuration I am missing that is somehow affecting
the read access to userPassword for the specific DN.

If you suspect your ACLs, you should show them to the list for evaluation.

[Owen Marshall]

Post by Marcelo de Moraes Serpa
Or maybe some ACL configuration I am missing that is somehow affecting
the read access to userPassword for the specific DN.

I'd bet this is the case.

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.

Use ACL debugging (olcLogLevel 128) to verify. Also, slapacl is a useful
tool you can use to verify your ACL setup.

Some worked ACL examples can be found here:
http://www.zytrax.com/books/ldap/ch6/#access