How to disable an LDAP account?

Question

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

Answer 1

You might be interested in trying slapo-ppolicy (Password Policy overlay), as suggested here. That's indeed a sort of standard, though it might be a bit overkill for what you're trying to do. Specifically, the interesting attribute is

pwdAccountLockedTime

This attribute contains the time that the user's account was locked. If the account has been locked, the password may no longer be used to authenticate the user to the directory. If pwdAccountLockedTime is set to 000001010000Z, the user's account has been permanently locked and may only be unlocked by an administrator.

Answer 2

Heh.

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.

Answer 3

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.

Answer 4

You say you use the posixAccount schema (RFC 2307). It comes with interpretation recommendations, but even you say that some services don’t follow it:

“several services use a successful authenticated connection to LDAP as simple authentication mechanism”

As a result: whatever your services do is already beyond the standard, so no need to keep looking at one. (RFC 2307 does not recommend that).

What (some of) your services do is nevertheless not that uncommon(?) and quite reasonable: using the bind operation in LDAP to test if some given credentials “work”. You can even enforce this type of central authentication by not revealing the userPassword attribute to any LDAP client. I.e. no reasonable posixAccount consuming implementation could ever use a missing attribute to successfully authenticate anyone, could it?

And how you disable successful bind operations for an LDAP poxisAccount in the server is a “private” server configuration question, not something to be debated in a standard, I guess.

If you have no power over the server itself (or potentially multiple servers themselves), only over the data in it, the trick to reversibly mangle the password(hash) into something un-matchable might do the trick.

Note, though, that some LDAP servers have flexible matching rules as Lasse Kliemann mentioned: changing a userPassword field from {ssha}asdasdfasdf to !{ssha}asdadsfasdf might lead them to believe the latter is a plain text password... If suffer from such a crappy configuration, {ssha}xasdadsfasdf should do it. Read the code to be sure. ;-)