Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've been wondering for a while if LDAP can be used to control user privileges. For example, if I have UNIX and web logins, is there an easy way to grant a user access to just or just UNIX (or even both?)

My current attempt at solving this very problem was to create 'login' and 'nologin' groups, but this doesn't seem fine-grained enough to meet the ideas I have in my head. I'm also still in the situation where all UNIX users are web users, which isn't a problem so much as an indicator of the limitations.

Does anyone have any input on this? Has this problem already been solved?

share|improve this question

You can can control access a few ways. RBAC is role based security. Groups are groups of users and roles are groups of access rights. You can map groups into roles or users into roles. In this case, your access rules might read like this:

"Allow everyone in HR to see the HR database" which in implementation would have users group into an LDAP groupOfUniqueNames object. This usually leads to a cleaner organization and most organizations aim for RBAC when starting from nothing. Whether RBAC is fine-grained is another question. For example, roles will control access to an entire document based on groups but won't discriminate down to the paragraph level for you. To some orgs, this is coarse grained.

A more simple approach if this sounds too complicated is to do ABAC (attribute based security) where your app/middle tier/whatever is controlling access by LDAP queries that look like this: "If you have an attribute 'foo' then you can hit the foo application." or "If your foo attribute has the value HR then you can hit the HR application."

The problem with ABAC is that it turns into a real mess. But for some things it's an easy check. For example, I might want people with uid, userPassword and mail attributes to be allowed into a webapp because those are the mandatory attributes my app needs. Then from there my app can look for roles and make more fine grained decisions. Login and nologin is really the queries (login=*) and (!(login=*)) which would allow access based on the existence of a single attribute. This is ABAC and it's usually not reusable and/or edge case scenarios will kill the design. As a contrived example, what if I have a system login for a cron job but I don't really want that system account to log into my app. If I set nologin (like shell to /dev/null or similar) then my cron job doesn't run, if I set it to login then my cron job runs but now a system account has the ability to log into my application needlessly. Create two roles (call them users and system accounts, whatever) and then create a policy that fulfills both requirements.

On an enterprise scale, organizations use identity management (IDM) products to centrally manage, report on and automate these access policies. Automation and reporting comes in handy when you have N systems across N sub organizations in a large company/organization.

share|improve this answer
You can get the best of both worlds with OpenLDAP's dynlist/dyngroup overlay -- RBACs created automatically based on a search. – James Cape Mar 25 '10 at 21:19

I have done this two different ways and used both at the same time even. First you can make people different ObjectClasses but that can end up being a pain. The other way was to create a groupOfNames with each person in it. I used this two things in combination to give people access to UNIX machines via their ObjectClass and then fine grained control to different web applications via groupOfNames.

share|improve this answer
it seems like this groupOfNames solution is similar to what I'm doing, correct? – neoice Nov 14 '09 at 13:31

You can handle authorization, depending on the underlying server that you are reading via LDAP.

For example in eDirectory, you could specify an object with attributes that users who have access can read the specific attribute value from.

Then you use eDirectory ACL's to allow or deny that.

Use the native ACL model, and then you can easily decide if a user has sufficient rights via LDAP.

share|improve this answer

Ultimately you need a way to tell one group of users from another and using LDAP/unix you have two options: have a LDAP query which discriminates (&(userName=konrads)(unixLogin=yes)) or using pam_* methods discriminate locally.

share|improve this answer

I've only had to do something similar once, and we added an attribute to our local schema, and assigned a value for each system that the user was allowed to log into.

Then, in the pam configuration, we had the search string include that they had to have that attribute set appropriately for that machine, so you might have something like:

(&(host:acad1)( ... test to make sure they weren't disabled ... ))

As 'host' was multi-valued, we could just assign as many hosts to the users as needed (and we assigned uidNumbers above 5000 for the LDAP accounts, reserving those below 5000 for applications, sysadmins and other local accounts.)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.