6

For a subset of my users in /etc/passwd, I would like to configure PAM (on Linux) to do the password checking part of the logon against an LDAP server, ignoring that these users are actually are listed as disabled in /etc/passwd. Specially, /etc/passwd and /etc/group should be used in all cases for UID and GID so that properties such as uidnumber and gidnumber do not need to be added to the directory (here, Active Directory) unlike what is usually shown in documentation such as LDAP Implementation HOWTO.

Is this even possible (without custom PAM module development)? It is not feasible to add properties to the LDAP directory. I am not the Active Directory domain administrator, and escalating involvement to that level is out of the scope of this project. It is a case where the system is operational in an environment that is mostly Windows servers; it would be nice if designated Windows users could use their AD passwords on the system in question.

Depending on the user, the user should be checked by UNIX auth or LDAP auth, but not both. I may not add attributes to the users in Active Directory, but may add them to security groups (and actually would like to further require that the LDAP users be in a specific LDAP security group).

5
  • And your question is?
    – HBruijn
    Nov 29, 2013 at 0:38
  • 2
    "how do I [x]" questions that do not supply research are not very popular on SF. It's a good idea to at least supply a few ideas you've had/things that you've tried, and explain why they don't suffice. It helps to avoid giving the impression that you want someone else to do the work for you.
    – Andrew B
    Nov 29, 2013 at 3:37
  • 1
    The answer is "You're doing it wrong". Tell whoever is saying you "can't add attributes" to the AD users to stop being a complete blithering idiot and use the RFC 2307 capabilities Microsoft ships with AD (they call it "Identity Management for Unix", and it makes AD work like any RFC 2307-compliant LDAP directory, so you don't need the "local files" hackery you're proposing: you can just use LDAP + pam_ldap or equivalent).
    – voretaq7
    Nov 30, 2013 at 8:09
  • 2
    I haven't tried it out yet, but the answer by Andrew B looks very useful. Removing this question might deprive others of useful information. To voretaq7, not sure why you adamantly assume that the administrator of one Linux system is also the AD domain administrator and that such a change to the production AD is trivial to get approved and implemented. Hypothetically, the users may even be in another domain in the forest so that a local domain admin can't even accomplish the change. Nov 30, 2013 at 18:16
  • @Jason Edit those details into the question and make it clear why the AD based solution will not work. The reopen queue will take care of the rest. (for the record, I was the first person to vote for closure, and also the first to retract my vote)
    – Andrew B
    Dec 1, 2013 at 0:20

1 Answer 1

9

Thanks for updating your question, that advice often gets taken the wrong way.

Your requirements as I understand them:

  • UID/GID lookups for all users must run against local files.
  • Authentication for specific users must try LDAP (Active Directory) first.

The short version is that yes, this is possible, but it requires actually understanding how these subsystems work and not relying upon online HOWTOs. I'm going to refer you to an existing answer of mine as a primer. https://serverfault.com/a/538503/152073

NSS is the system that performs the UID and GID lookups. If you don't modify /etc/nsswitch.conf and tell it to use ldap or sssd, your system calls will rely on the local files. Most of the PAM plugins for LDAP share a configuration file with a NSS plugin for LDAP, but that won't matter if the NSS plugin isn't being used by NSS.

Your requirement to only do this for specific users is trickier. Configure PAM to try pam_ldap.so (or pam_krb5.so, or pam_winbind.so...depends on which you're using) as auth sufficient, immediately before auth required pam_unix.so. sufficient means "good enough, stop here". required means "if we got this far and this test failed, authentication fails".

This is the simplest method, but there are problems:

  1. It will result in AD password lockouts if someone is frequently authenticating with a local password that does not match their AD password (i.e. they not authenticating successfully against AD as often with other systems).
  2. This would also not work for your requirements if you don't want valid AD passwords to be considered for certain users.

Let me know if you really, really, really only need to authenticate against LDAP for a specific list of users. It is definitely possible, but it will increase the complexity of the PAM configuration and I'm already throwing quite a bit of information at you.


Expanding upon the answer as requsted:

My recommendation for tight control over who authenticates against AD is to use pam_access.so. For this to work, the AD and Unix PAM modules must be adjacent, and in that order. Place the following line in front of them:

auth    [success=ignore default=1] pam_access.so accessfile=/etc/security/somefile.conf noaudit

success=ignore means "if this test succeeds, ignore this line and proceed as normal". default=1 means "in all other cases, skip the next line". You will need to create somefile.conf and define a list of users who are allowed to use AD auth. Check the manpage for access.conf for more details. You will either define a list of all users in this file, or create a local group and test for membership. In all cases, the third field should be ALL. (i.e. + : whatever : ALL)

Your optional requirement (control this with an AD security group) can be implemented one of two ways:

  1. If your PAM module allows you to specify a LDAP query that will cause auth checks to be skipped based on group membership, use that. This is not the same as rejecting the user via account if the password succeeds!
  2. Compromise on GID lookups hitting active directory. This means you would have passwd lookups point at ldap in /etc/nsswitch.conf, but you would add the ldap line to group. The security group object must be configured so that it can be recognized as a Unix group, either by applying the appropriate objectClass (i.e. posixGroup) or configuring the NSS plugin to recognize it as one. Unless you have a strong background in LDAP, you may just want to pass on this.

Once you've successfully configured things to the point where getent group is showing the AD group, you can modify your access file to succeed based on membership of that group.

4
  • Thanks. Yes, #2 may be an issue. On the Linux system, I would prefer to control which users always use LDAP passwords and which ones always use local passwords (there really is never a need for fallthrough to a local credential). And I might like to require that the user is a member of an AD security group, if easy to do. Nov 29, 2013 at 20:30
  • Okay, I warned you. Answer updated. :)
    – Andrew B
    Nov 29, 2013 at 21:04
  • 1
    For group requirement: in /etc/pam_ldap.conf, pam_filter &(objectClass=user)(memberOf=cn=Linux Users,cn=Users,dc=dom,dc=local) Nov 30, 2013 at 23:16
  • Nice tweak. I was thinking that those checks would fire inside of the account stack instead of the auth stack, but a quick Google seems to suggest that you're right.
    – Andrew B
    Dec 1, 2013 at 5:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .