Difference between expired account and inactive account

Question

After a command like:

$ usermod -e <yesterday> -f <tomorrow> bea

Bea's account will be expired, but still active (until tomorrow).

What's the difference? What could happen yesterday and can't happen today? And what can happen today but not after tomorrow?

Solution 1

usermod -e normally takes a date as a parameter: if you specify usermod -e 2019-12-31 joeuser, then Joe User's account will only work until the end of the year, and no more, unless an administrator re-enables the account, either by setting a new account expiration date, or by using usermod -e "" joeuser to allow the account to be enabled indefinitely with no scheduled expiration time.

You can also use usermod -e 1 joeuser to disable the account immediately: this will effectively set the account to expire on Jan 2, 1970 which is firmly in the past.

Disabling an account like this works for all authentication mechanisms: even if the user uses SSH keys, smart card, RSA SecurID or any other authentication mechanism, that account will not accept logins. When the account is disabled like this, there is nothing the user can do alone to re-enable it: the only recourse is to contact a system administrator.

Note that this account expiration is completely separate from password expiration.

---

usermod -f, on the other hand, expects as a parameter a number of days. This is a clock that starts ticking when the user's password expires: for example, if you set Joe User's password to expire in 90 days (passwd -x 90 joeuser) and usermod -f 14 joeuser, then once it has been 90 days from the last time Joe User changed his password, Joe will have exactly 14 days of time when the system will force him to change his password if he attempts to log in. If he does that, the new password will again be valid for 90 days.

If Joe won't log in within those 14 days, the account will be locked and Joe will need to contact an administrator to unlock it if he needs to access the system still.

---

Note that historically passwd -l used to mean locking the account; with the modern Linux PAM implementation, it actually means locking the password only. If the account has SSH keys or some other authentication methods configured, they will still be allowed even after a passwd -l.

The current recommended way to completely disable an account without removing it or changing its configuration (so that it can be re-enabled exactly as it used to be, if desired) is usermod -e 1 <username>. This is guaranteed to be equally effective with both new and old PAM implementations.

Changing the user's shell to /bin/false or to a command that displays a message and then exits, will also work to disable command-line login for any authentication method, but as a side effect, the information about the user's current shell will be lost. Also, if the system has other services like email or FTP that use the system passwords for authentication, changing the shell may not disable access to them.

Solution 2

I'm not 100% sure, because I can't test now, but if I don't remember wrong that -f flag is the third from last field of /etc/shadow. That field is the time the account must be "inactive" (nobody logs in) before the system disable it. The -e switch is the expiration day of the account. The two fields are unrelated.

Comments

[Kusalananda]

Not an answer (as I have no Linux system to test on): An expired account (actually, an expired password) needs to have its password changed before allowing login. The user will be forced to do so upon login. After the number of days indicated by the argument to -f, if the password hasn't been changed, the account is locked and requires admin intervention to unlock. You should be able to test this fairly easily with a temporary account set up for this single purpose.