4

With passwd -S user_name one can find out, if an account is locked, but is there a way to find out when it was locked and who it locked?

Further links:

Community
  • 1
Framester
  • 1,633

2 Answers2

3

Currently, yes and no. The security system itself doesn't log historic details of password changes. Since it's a flat file it would be hard for such a record to be accurate and trustworthy, if access to the databases had to exclusive go through some kind of a broker then it would be possible (you could just add the logic to the broker), but with widely accessible flat files, not so much. This is why a lot of LDAP/Kerberos identity services allow this type of auditing but local unix users have a hard time with it.

The closest you can get is to enable operating system audit logging, log all command executions (with command line options) and watch the /etc/passwd and /etc/shadow files. If you can trace the change to being in a certain time period search for in the OS audit records, you might be able to trace it back to a "passwd -l" invocation or someone manually editing /etc/shadow or /etc/passwd (in case of unshadowed password).

EDIT:

To clarify, the default passwd utility on some versions of traditional UNIX (Like Solaris 9, I'm seeing) will syslog the "passwd -l" but I assumed we were on Linux given the GNU version of passwd and that that's still insufficiently complete to be trustworthy.

erch
  • 5,030
Bratchley
  • 16,824
  • 14
  • 67
  • 103
  • What do you mean with "Since it's a flat file**" (1st paragraph, just curious) – erch Dec 11 '13 at 17:15
  • Because then at most you would have to configure auditd such that it logs when someone opens the file for writing. So you get the event, but it's no guarantee that anything was changed or what was changed. The only way of knowing that would be to have some secondary Host-based IDS like AIDE or Tripwire. They'll keep internal copies of files so they can diff them. But even then, if two edits happen to /etc/passwd during the same sample period by two different people you have a hard time tracking which change to what user. – Bratchley Dec 11 '13 at 17:38
  • Like for what the OP is wanting, Host-based IDS can get you close but it leaves a lot to be desired. There's no reliable/deterministic way to figure that out. Everyone is just referencing the contents of the same file. Kerberos/LDAP have a broker process with exclusive access to the data source, so you can log the requests at the specific item they're wanting to modify (in this case I guess it would be which process munged the password field). – Bratchley Dec 11 '13 at 17:43
  • @chirp http://en.wikipedia.org/wiki/Flat_file#Flat_files – goldilocks Dec 11 '13 at 18:04
1

You could go through your system backups, looking for two consecutive backups (N and N+1) where the user is locked in /etc/passwd in backup N+1 but not in backup N.

Scott - Слава Україні
  • 10,519