Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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:

share|improve this question
    
On which unix variant? –  Gilles Apr 12 '13 at 22:01
add comment

2 Answers

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.

share|improve this answer
    
What do you mean with "Since it's a flat file" (1st paragraph, just curious) –  Chirp. Not Luke. 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. –  Joel Davis 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). –  Joel Davis Dec 11 '13 at 17:43
    
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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