LDAP Debugging


#1

I’m looking for a little help in debugging the LDAP functionality. I have successfully set up a connection to the DC with an admin user, and confirmed that Metabase successfully saves the changes - when I put in a bad address for the DC I get the expected logging in the console.

When I try to login, I always encounter the error “Password: did not match stored password.” I’ve tried a number of different user filters and tweaks unsuccessfully and am wondering if there is any way to get any of the logs for these attempts to diagnose the issue?


LDAP Idiot's guide
Can connect the ldap server,but can not login in with the ldap user
Trouble configuring LDAP
Working Settings for Open Directory (Apple's LDAP)
#2

Nothing solves a problem like the power of asking the question… I figured out my issues and want to post some of what I found for others, as I am an LDAP newb.

When we contacted Rackspace to ask for our User Search Base for this, they instructed it was:

CN=Users,CN=Builtin,DC=ourDomain,DC=com

That got us nowhere.

LDAP Hierarchy

I had no idea what these acronyms meant or what our universe of possible variables were. If that’s also your scenario start with this StackOverflow overview on LDAP hierarchy.

Now that I knew what these acronyms meant, I saw another post that just used an OU and the DCs (no CNs), so I decided to try that… but first I needed to know what OUs were in our network.

Find your OUs

For testing purposes, you can find out your OUs through a script like this OU Script

Start with the top-level parent OU for your testing purposes, and if that works, go ahead and start dialing into your Child OUs (or create your Metabase one and add people).

Dialing in on attributes and search filters

When buckling in the security, you might want to see what OUs and Groups your users are already a part of. A good tool to peer into your world of AD stuff is the AdFind Tool by joeware. Using a command like AdFind.exe -h ourDomain.com -f userPrincipalName="myUsername*" can show you a ton of info about your OUs, CNs, and memberOfs.

Now that you have that knowledge, you might want to start figuring out how to read and define search filters, and Atlassian provides a great overview here.

Finally, dialing in on the memberOf and the associated rule OIDs can be given light with this Microsoft overview.

Tweaking the settings

Our initial working settings ended up looking like this:

LDAP Authentication - Enabled
LDAP Server - domainController.ourDomain.com
LDAP Port - 389
User Search base - OU=MyBusiness,DC=ourDomain,DC=com
User Filter - (&(mail={login}))
Attributes
  Email Attribute - mail
  First Name Attribute - givenName
  Last Name Attribute - sn

That was nice and worked well for the regular users who had Exchange mailboxes, but we also had some contractors who had domain accounts without mailboxes, so they couldn’t log in with this setup - we needed to use the userPrincipalName instead of mail. So we changed it and confirmed the userPrincipalNames with AdFind for each user. Here is our current setup:

LDAP Authentication - Enabled
LDAP Server - domainController.ourDomain.com
LDAP Port - 389
User Search base - OU=MyBusiness,DC=ourDomain,DC=com
User Filter - (&(userPrincipalName={login}))
Attributes
  Email Attribute - userPrincipalName
  First Name Attribute - givenName
  Last Name Attribute - sn

Also, I liked this approach from another answer on this site:
User Filter: (&(|(sAMAccountName={login})(userPrincipalName={login}))(memberOf:1.2.840.113556.1.4.1941:=cn=Metabase,ou=Services,dc=example,dc=org)). See how they used the OR (|) pipe to match on one of those two login possibilities of userPrincipalName or sAMAccountName? Pretty good approach to make it convenient for users to login.

The Invite

One final note, if you don’t “invite” the user through the People page in the Admin portal, then the user’s login process could result in landing back on the login page. I’ve seen this happen intermittently. Go ahead and “invite” them, and then they should be able to login with their LDAP creds. Uninvited LDAP users whose creds are in the Search Base and pass the User Filter may be able to sign in/up without an invite.

In Conclusion

I think that if you are getting a “Password: did not match stored password.” you have either a bad User Search Base, bad User Filter, or both.


LDAP Idiot's guide
#3

Apache Directory Studio (http://directory.apache.org/studio/) is a useful tool when debugging LDAP issues.


#4

Is there a step-by-step guide on testing out and debugging the LDAP setup?

In my case we have a domain in front of a user id, but I’m not finding any output for the attempted LDAP connections and queries, just the post & get from changing the settings.

And it looks like you need at least 2 people to test with in an enterprise environment? You can’t test with just yourself?

In our case we have user IDs stored in the CN field. So my filter is the following.
(cn={0})

Am I just hopeless?


#5

Hi, did you manage to resolve your problem? My environment too use user ID in CN field. I tried cn={login}, didnt work