3

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?

Lasse Kliemann
  • 318
  • 2
  • 9
  • 1
    I believe you are correct. You should reformulate this a Q&A pair. – Sven Sep 14 '19 at 11:23
  • 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 '19 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 '19 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 '19 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 '19 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 '19 at 14:46

2 Answers2

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.

Timothy Booth
  • 11
  • 1
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).

Lasse Kliemann
  • 318
  • 2
  • 9