SU / logging

[Nobody's Hero]

When a user logs in as themselves, that is a personal user account, we make them 'su' to oracle or other special user accounts. Problem is , when they su to oracle or other accounts, they end up getting reported as a dormant account because they have not logged onto the system in 'x' amount of days. Anyone know why this is happening? The audit keeps hitting oracle and other accounts as 'dormant'.

Do accounts not show up in the last log if they are initiated by 'su' ???

[James R. Ferguson · Accepted solution]

Hi Robert:

No, 'su' activity is not logged in '/var/adm/wtmp'. Rather, the switch is shown in '/var/adm/sulog'. This makes "sense" since to perform a (s)witch-(u)ser you must already be logged on.

You can tell the success (+) or failure (-) from the 'sulog' with the positive/negative notation recorded for the action.

Regards!

...JRF...

[Jeff_Traigle]

Welcome to the wonderful world of account access logging. It's a mess. As you've discovered, su logins are not recorded in wtmp so will not show up in last's output. The only place such logins are recorded in sulog and/or syslog, depending on the configuration.

[Steven E. Protter]

Shalom Robert,

Seems reasonable that with last -R output and the sulog you can write a short awk script and have a very good idea what is going on.

oracle and other accounts may be dormant if the dba's never log on. Your startup scripts will only leave evidence in the sulog.

su - oracle -c run by root. Did Orale log in? not as afar as wtmp is concerned.

SEP

[Tom Henning]

If this is a trusted system it might be better to write a script to run through the users doing a getprpw on each user. The slogint field will reflect a sucessful login date event for a su. Of course, this means that root has to be the one to be getting the login dates for the auditors, but at least this can refute the "dormant account" claim.