Testing User Authentication with ldapwhoami – How to Guide

ldapopenldap

I am working on a ec2 instance running amazon linux (similar to centos). I have a ldap server set up using open ldap. It appears to be working, but I can only authenticate the admin user, not other users i attempt to add.

If i attempt to test the authentication for the admin users with:

ldapwhoami -x -D "cn=Manager,dc=mydomain,dc=com" -w mypassword

it works just fine. This is a good start!

But I also need to be able to test user authentication. For example I've added a test user tsmith. I attempt to query this user with:

ldapwhoami -x -D "uid=tsmith,ou=users,dc=mydomain,dc=com" -w testuserspassword

I get the response:

ldap_bind: Invalid credentials (49)

I've made sure that the ldap server contains the users and groups that I expect it to. Using "ldapsearch -x -b dc=mydomain,dc=com" i can see the correct users, in the correct groups. The user I'm interested in appears as:

# Test Smith, users, air.local
dn: cn=Test Smith,ou=users,dc=air,dc=local
cn: Test Smith
sn: Smith
objectClass: inetOrgPerson
userPassword:: [password hash here] 
uid: tsmith

Does anyone have any tips about what I might be doing wrong?

Best Answer

uid=tsmith,ou=users,dc=mydomain,dc=com is NOT the DN, that is cn=Test Smith,ou=users,dc=air,dc=local and you need to use a DN to make a bind with a -D

Related Solutions

Ldap – Securing userPassword access with OpenLDAP in RHEL

pam_ldap shouldn't be attempting to read the userPassword value to log you in -- It logs you in by doing an LDAP bind with the DN that it retrieves.

It's possible the search parameters pam_ldap uses are over-broad & it tries to pull userPassword as a result, but if your ACL is set up correctly (looks fine to me) it won't get that value in its results.

Just in case your ACLs aren't fine (I've been known to miss stupidly obvious stuff before), here's the working ACL list from my production LDAP environment :)

# Access and Security Restrictions
# (Most restrictive entries first)
access to attrs=userPassword
    by self write
    by dn.sub="ou=sync,dc=mydomain,dc=com" read
    by anonymous auth
by users none

access to * by * read

The trailing access to * by * read is important, I didn't see it in your examples so I'm not sure if it's missing or just omitted from your snippet.

The sync line is for my LDAP synchronization service and isn't necessary if you're not doing replication...

Ldap – How to configure LDAP in ApacheDS to use uid for authentication

With that particular object, it's unlikely that you can. LDAP is looking for you to bind with the distinguished name (DN) of the object, and the primary attribute in this case is cn. This is a deliberate design decision because there is no guarantee that any given attribute of objects within a container will be unique other than the one that is associated with their DN.

This will not stop services from being able to search your directory and determine that uid=lawrence is associated with that particular DN (and thus being able to find any other attributes needed off of that object), but any calls that explicitly need to be run against a DN can only be run against the primary attribute.

This isn't to say that there aren't ways that you can avoid specifying a DN. Implementing SASL authentication and defining a map between SASL IDs and DNs comes to mind. But within the context of your question, no, you cannot switch to using a non-primary attribute of the DN you're authenticating to in place of the DN.

Related Topic

Linux – LDAP+SAMBA login issues