Home / server / Questions / 558103
Accepted
Jason Kresowaty
Asked: 2013-11-29 09:55:44 +0800 CST

How to use PAM to check LDAP password for some users, yet always use UID/GIDs from local files?

  • 772

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).

linux

1 Answers

  1. Best Answer

    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.

    • 9