Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

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

The LDAP uses the posixAccount schema and related attributes and I wonder if there's a standardized way to disable an account. Re-enabling the account should obviously re-enable the former password.

I know that passwd --lock adds an exclamation mark in front of the encrypted password in /etc/passwd. Does the same convention work with the userPasswd field of an LDAP entry?

Update: I know PAM/NSS underneath, my question was specifically targetted at the LDAP server. Once the account is locked I want the user to not be able to open an authenticated connection to the LDAP server itself (with his own credentials). That's because several services use a successful authenticated connection to LDAP as simple authentication mechanism without using PAM for this task (this is common with web interfaces).

share|improve this question

There is no standard way but there are several ways to accomplish this, each being a configuration option in ldap.conf (or pam-ldap.conf depending on your distribution and their pam_ldap build-time settings):

pam_filter: Use a custom filter together with an attribute in LDAP that denotes an inactive account.

pam_check_host_attr: pam_ldap will check if there is a matching "host" attribute on the user object. If you implement it this way you could just remove/add the hostname to this attribute if the user should be able to login. This would not touch his password.

pam_check_service_attr: Haven’t used this yet but should work in a similar way as pam_check_host_attr.

share|improve this answer
Thanks but I was wondering if the LDAP server itself had a convention since it manages authentication for connection to itself without PAM... – Raphaël Hertzog Sep 3 '10 at 7:58
Regarding your update: If that's what you want, go with Janne Pikkarainen's advise about prefixing the userPassword attribute with a "!" this will render the user unable to do an authenticated bind to LDAP without discarding the password. – Fladi Sep 3 '10 at 8:14


Unix/Linux and a standardized way to do something. Funny lad you are. I know, I know, in many cases there are standard ways of doing things, but LDAP certainly is not one of them. LDAP rhymes with the Perl motto, "There's more than one way to do it".

The same convention than in the /etc/passwd (or, in /etc/shadow to be precise) will work. Undernearth your system is using the PAM (for authentication) and NSS libraries (for name lookup) for resolving the account information and for userland applications it's transparent if the result arrived from pam_ldap, pam_mysql, nss_files, nss_bdb, nss_mysql, nss_ldap or some other source as long as it's in the standard form.

So, when it comes to LDAP ...

  • Some like to write their own scripts utilizing ldapmodify
  • Others use graphical clients such as gq or Luma
  • Others use Perl and Net::LDAP or other scripting languages and their LDAP bindings
  • Others use PHPMyAdmin and similar web interfaces

What's your preferred way? If using the passwd command, then you just need to hook your system with pam_ldap and nss_ldap. Then all the familiar utilities will continue to work as usual.

share|improve this answer
How does this solve the problem of disabling particular accounts in LDAP so that PAM recognizes them as disabled? – Fladi Sep 1 '10 at 9:22
"The same convention than in the /etc/passwd (or, in /etc/shadow to be precise) will work." is the line that helps. If Raphaël already has a method for prefixing the old passwords with !, then I just answered his question. How does your comment help him? :-) – Janne Pikkarainen Sep 1 '10 at 9:25
Thanks but I was wondering if the LDAP server itself had a convention since it manages authentication for connection to itself without PAM... see my update in the question. I'm writing code in PHP so I use the php_lpad binding to modify the LDAP. – Raphaël Hertzog Sep 3 '10 at 7:59

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.