I need to check actual date a user was disabled on my HP-UX server.
Audit is claiming the user account was active during the last audit exercise.
if you do not get better suggestions ...
look at time stamp of affected server's /etc/passwd file first to see last modification date. if after audit date, have somebody restore a copy of the /etc/passwd file from the date of the audit to confirm prsence of specific account.
We would need to know a bit more on your architecture, (paltform, OS and version, using shadow? ot TCB?) and the context
What was the audit doing?
I saw cases (audit...) with active intrusion attempts, resulting in some users account to be disabled...
So you would have to explain what is the claim... ( and kind of disablement...)
Are you in trusted mode? You can tell by looking to see if there are files under /tcb/files/auth If there is, then under this point, there is one character a directory for the first of each user name and within there, there is a file for each user. Look at the timestamp of the file to see the last update of it, however if it has been attacked (someone tried to use it) then this will have been updated.
Within, there are fields describing last successful login, last failed login, last password update etc. The times recorded are in seconds from 1/1/1970 00:00:00 (the Epoch) so someone here helpfully wrote this bit of Perl that reformats it to make it human readable:-
perl -e 'print scalar localtime $ARGV[0],"\n" ' $1
I have this as a one-line script, so I just run something like:-
$ realtime 1234567890
Fri Feb 13 23:31:30 2009
I hope that this helps. If you are not in trusted mode, then it depends if you clean out the login history files (whatever they are) Try using the last command. Read the manual pages for the options. It might be useful, maybe not. Unless you intercept and log every use of the various user admin commands (useradd, modprpw, passwd etc.) it's going to be difficult to really prove anything.
As a more general question though, are the auditors complaining that the id they used last time to probe around has been suspended? If it's more that a month since they last used it, then I think you have every right to suspend it to limit the risk of attack, in fact you could argue that it should be suspended immediately after they have finished using it.
i understand they have an important job to do, but sometimes they are the worst offenders just asking for open access whenever they want it. Enforce your standards, especially with them. It could be a test of your procedures 
Robin
Liverpool/Blackburn
UK
1 Like
having my fill of audit requests, the issue is more likely the auditors saw an account of a terminated employee still active when they last did their audit. since auditors ask for copies of the user-related security files (i.e., /etc/passwd, etc/group, etc.) during an audit, they are able to correlate the listed users with currently active employees/consultants so any account that stands out needs to be reviewed.
Yeah, yeah, yeah. Often just a pain with technicalities. perhaps they should just be happy that an account has been suspended, unless they want to match it to a notice about someone leaving and date it to quantify the risk for the time between leaving and the suspend date.
Any luck with files under /tcb/files/auth giving you dates? I think you can configure accounts to lock if unused automatically. Add that to the last successful login and you may have an answer for them.
Good luck!
Robin
unfortunately, compliance requirements obligate us to remove user accounts of terminated employees as soon as notified. we may not like what audit does but we are stuck with them.
Join the club. :rolleyes:
I don't mind them too much when they ask intelligent and probing questions. I worry when they just ask for /etc/passwd and the shadow then nit-pick over saying that they can read the password, e.g. AIX has /etc/security/passwd with a format like:
root:
password = Xlen7kw02f234
lastupdate = 1894726232
Of course, they never actually try to login with the encrypted password to prove it.
I have even fed them a little nugget or two when I've been prevented from doing the right thing because someone didn't plan properly and that gets the profile raised and hopefully the issue fixed.
It's a bit of a game to keep us on our toes and them justifying their job.
Good luck.
Robin