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?

  • why not just change the password of the user?
    – Kiwy
    Feb 4, 2014 at 16:18
  • That effectively changes their state (unable to login), but it doesn't serve as a marker or anything we can check. For example, if we want to get a list of all users who are deactivated, we can search for anyone without a valid loginShell. Feb 4, 2014 at 16:27
  • In my short memories playing with LDAP, you can ad almost every thing you wnat to a user, why not a flag disable and in the same time change there password and shell
    – Kiwy
    Feb 4, 2014 at 16:29
  • Yeah, we could definitely add a "isDeactivated" LDAP attribute or something like that, but then I'm not sure how to perform that check upon every login attempt. Feb 4, 2014 at 16:30
  • 2
    This SF Q&A looks related: serverfault.com/questions/176834/how-to-disable-an-ldap-account
    – slm
    Feb 4, 2014 at 17:09

1 Answer 1


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

You must log in to answer this question.

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