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.