0

Background

Another team within our organization has a fully configured Active Directory server. My team builds Ruby on Rails applications and we authenticate users of our web applications against their setup. Due to some new security policies that are being put in place, our development machines will no longer be able to talk directly to the production servers. As a result, I'm trying to install OpenLDAP on my local machine (running Fedora) and use that to authenticate users when I'm developing.

Setup

I have been able to fully configure OpenLDAP and insert a record. My database looks like:

dc=dev,dc=com
     ou=Users
           cn=User 1

Inside the cn=User 1 entry, I have an attribute called accountName and I also have the standard userPassword attribute. As a test, I downloaded an LDAP browser and I'm able to successfully authenticate when I specify the full DN (cn=User 1,ou=Users,dc=dev,dc=com) and give the password that's in the userPassword field.

Question

In our production environment, all I have to give for authentication is the base DN (dc=dev,dc=com), the value for an accountName and the associated password. Once I authenticate, I'm able to access the other fields in the User 1 entry. What do I need to do to authenticate using the accountName field instead of a full DN?

Improve this question

1 Answer 1

Reset to default
1

There are two things to address here:

First off, if your production environment is ActiveDirectory and you can't access it from your developer workstation, ask the team in charge of the AD environment to create a "dev" environment that you can access.

While the basic concepts of LDAP are standardised, the implementation specific details will vary greatly between AD and OpenLDAP.

Secondly - the way that most^ software is able to authenticate against LDAP using just a username and password is thus:

  1. User: submits a form (web, native app, whatever) with their username and password
  2. Login process: binds to the LDAP server, either anonymously, or with a fixed service account DN and password.
  3. Login process: does an LDAP search for the supplied username, matching against which ever attributes are relevant for the environment (e.g. "accountName" in your case)
  4. Login process: fetches the DN of the found record (if any)
  5. Login process: attempts an authenticated bind using the fetched DN and the supplied password from step 1.

Edit:

^ In some situations, the username supplied is the value component of the user's RDN, e.g. if my login is stephenr, my user entry's RDN might be cn=stephenr. If this is the case, and all user entries have the same parent object, the DN to authenticate as (step 5 above) can be created just by building a string, e.g. "cn={userid},ou=users,dc=example,dc=com" where {userid} is replaced with the supplied username value in step 1.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Thank you. This was very helpful and we ended up using this to do a pretest to see if an account is locked. If anyone else is using a similar development environment, there's a slightly different approach which will save you a call to the LDAP server. Since the DN structure is known in the development environment, you can dynamically build the DN string when you're in development mode, and then just use the regular username when running in production mode. Rails in particular makes this easy since you can ask Rails if it's running dev or prod.
Yes, for some environments (even prod environments) it's perfectly acceptable to build a DN from just a username, if the structure is known to be "static". this is what the footnote in my answer refers to. I'm glad you got it working!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.