We use LDAP for authentication for thousands of users. The primary tactic we have been employing to make a user unable to login, without removing their account, is to change the LDAP attribute "loginShell" to something like "None" or "NA", as opposed to "/bin/bash". What this does is upon login attempt throw the user "Permission Denied." I'm not sure if this setup with LDAP and the "loginShell" is a unix standard, or specific just to our environment here.
My question is, is this a sufficient measure for disabling an account, making a user unable to log in? Are there any holes or workarounds in which a user could still log in? Are there any other steps we can take to disable an account?
Best Answer
Changing the user's shell only "definitely" changes what gets executed if they attempt to log in and start a shell. It does not by itself invalidate access. So, someone might be able to run
ssh host -t /bin/sh
in order to run a command, or might still be able to log in via ftp or a web app using this repository.You could make this work, however, by checking for a valid login shell before allowing access. You could do this with an LDAP filter. Or, on most Linux systems (and several other PAM-enabled UNIX variants), you could use something like pam_shells, which checks to see if the user's shell is listed in /etc/shells before allowing access.
Traditionally, shell-based login access is done by either setting the shell to /bin/false or setting it to /bin/nologin (if it exists). Using pam_shells or an LDAP filter renders those solutions "mostly" pointless. However, I like to put /bin/true in /etc/shells so that I can discourage shell access for some users while allowing them in with something like scp; I then put /bin/false in for users who shouldn't get any of those, and use pam_shells on the services where I want to use the shell to switch things.
Most of the time, with LDAP you can provide an attribute which controls access. With Linux pam_ldap, the "pam_check_service_attr" option allows you to list specific pam services to which this user can authenticate (using the "authorizedService" attribute). There's also a host-based access attribute.
But really, the answer to your question depends very strongly on the capabilities of the software with which you're connecting to LDAP. :)