4

In this answer, is was suggested that the UNIX way of adding a ! in front of the password field would work. I claim that this is not a clean solution. It will not make logins impossible, but merely it changes the password to the literal content of the password field (of which the first character is !).

For example, assume the password field now looks like this:

!{CRYPT}$6$rounds=1000000$xxx$yyy

Here, xxx stands for the salt, and yyy for the hash. That string will now be the user's password. For many practical purposes, this means the user cannot log in anymore, since she does not know her salt. But, in theory, by guessing the salt, login is still possible. Even worse, if an attacker obtains the LDAP database, he can now easily log in to this "locked" account, since hashing apparently is no longer used.

How can it be done instead?

Improve this question
5
  • Note that just adding the ! right after the {CRYPT} should work as well. The same is true if you use the builtin hash methods like {SHA} or {SHA512}. That might make it easier to do this in a script if you just have to replace } with }!.
    – Sven
    Sep 14, 2019 at 11:31
  • Very important though: Doing this does not prevent users from logging in with an SSH key, as in that case, LDAP is never asked if the PW is correct. Set the shell to /bin/false for that case (as a first step).
    – Sven
    Sep 14, 2019 at 11:36
  • Indeed, very important point. I'm now wondering: which cases are not covered by setting shell to /bin/false as the only measure?
    – Lasse Kliemann
    Sep 14, 2019 at 11:45
  • One short test: I am using sssd, which caches user entries, including the shell. Until the cache entry expires or gets flushed, you can still login with the key and change back your shell (I guess nscd would act similar). Better remove the authorized_keys file. In one older environment I run, my user deactivation process includes renaming authorized_keys and replacing it with an empty one owned by root with 600 permissions.
    – Sven
    Sep 14, 2019 at 12:23
  • Beware that unless also the ownerships of the parent directories are changed, a user could (e.g., via a cronjob that was configured in advance) still replace authorized_keys, even if it is owned by root. I suggest changing the user's primary group instead and use DenyGroups in the system sshd_config.
    – Lasse Kliemann
    Sep 14, 2019 at 14:46

3 Answers 3

Reset to default
1

Change the password field to the following:

{CRYPT}!$6$rounds=1000000$xxx$yyy

Or the following:

{CRYPT}$6$rounds=1000000$xxx$!yyy

According to my tests, this makes password authentication impossible.

It does not, however, cover other ways of authentication, for example with an SSH key. In order to cover those, at least the shell should be set to /bin/false. I strongly recommend to combine this with another measure. In the comments, it was suggested to disable ~/.ssh/authorized_keys. A probably safer way is to change the primary group of the user to a group that is not allowed to SSH into the machine (the DenyGroups or AllowGroups feature of SSHD can be used for this).

Improve this answer
1

If you don't need to retain the existing password hash, you can simply delete the userPassword field from the LDAP entry. Of course if you re-enable the account the user will need to set a new password.

Improve this answer
0

The proper way to handle this is two-fold:

  1. make sure all services do authentication and a separate authorization check

    • SSH can bypass the login-shell and LDAP password authorization (by specifying a command to execute and using key-based authentication), and such a config is reasonable!
    • popular SSH servers can do authorization checks with PAM even if they handle authentication themselves without PAM/LDAP (usePAM → that uses the “account” category in PAM on top of only possibly using “auth”)

  2. make sure authorization checks e.g. the shadowExpired attribute (shadowAccount object class) in your setup, and then expire the account

I see little reason to mutilate the password in a way of being able to recover it while mutilating the login shell without being able to recover that one.

Moving the entire LDAP user entry into a different subtree on the LDAP server should disable that account pretty good as well.—With the disadvantage of no being able to see the user and group names in e.g. the left-over home directory. And your user management tool might decide to reuse the uid/gid numbers prematurely if it can’t find an entry using them.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.