Trusted system password expring

[John Oberlander]

I have a 11iv1 trusted system with a user that the programmers are having problems with. They say that the password expires everyday even though i have password aging disabled. What is the minimal auditing do i need to turn on in order to see what happens? I don't see anything in the auditing events that would give me this info in the logs.

Thanks,
John


universe@/usr/lbin: ./getprpw abatmgr
uid=1851, bootpw=NO, audid=424, audflg=1, mintm=0, maxpwln=-1, exptm=0, lftm=0, spwchg=Tue Oct 24 06:37:47 2006, upwchg=Mon Sep 11 08:40:18 2006, acctexp=-1, llog=-1, expwarn=0, usrpick=DFT, syspnpw=DFT, rstrpw=DFT, nullpw=DFT, admnum=-1, syschpw=DFT, sysltpw=DFT, timeod=-1, slogint=Wed Oct 25 09:09:55 2006, ulogint=Tue Oct 24 21:25:13 2006, sloginy=pts/tai, culogin=-1, uloginy=pts/t1, umaxlntr=-1, alock=NO, lockout=0000000

[Jeff_Traigle · Accepted solution]

Is it really expiring, requiring them to select a new password, or is the account being locked so they can't login at all? Offhand, I would suspect the latter, in which case, you can check the lockout value of the getprpw output to see why the account is locked. From the getprpw man page:

lockout returns the reason for a lockout in a "bit" valued string, where 0 = condition not present, 1 is present. The position, left to right represents:

1 past password lifetime
2 past last login time (inactive account)
3 past absolute account lifetime
4 exceeded unsuccessful login attempts
5 password required and a null password
6 admin lock
7 password is a *

[John Oberlander]

I have the lockout period to be 5 unsucessful attempts. Lastb dosen't show any bad attempts, so i dont believe its that. I think the programmers are screwing with me, i just need to get the minimal amount of auditing turned on to prove otherwise. They say it's expiring, but they haven't sent me a screen shot where it says it expired and to choose a new password. Everytime i check the getprpw, the lockout is always zero's. I guess i can set up a script to check the account every hour and log the output to see what lockout bit is set.

Is there a way to tell what was the last reason for the password change, even though the account isn't currently disabled/expired or locked?

Thanks,
John

[Bill Hassell]

The lockout code is a series of 1's and 0's with the position of a 1 indicating the reason for the lockout. I have attached a script which decodes all this and a bunch of other user status details. Mainly, it can verify that the user account is not locked.

As far as the users that are complaining, they need to copy the screen when there is a failure. Another test is: are all users affected, or just a few programmers? Add a dummy user and check the login every day. Just in case, look at .profile for users with a problem. Is there a strange command or sourced file that doesn't appear in root's .profile (possible hacker loose)? Are the programmers using /usr/bin/sh or some other shell?

[John Oberlander]

Thanks for the script! So what im reading is that there is no way to find out when and why an account was previsoully locked if it's already been unlocked. I'll write a script that will check the lockout bits every half hour and to let me know if and when it does.

Thanks for the help,
John

[John Oberlander]

Thanks for the help.