Solaris

Hi,

I have a Solaris 10 box where password aging is not functioning properly. Using the passwd command with the -l or -u options causes the lastchg field in the /etc/shadow file to be modified. Therefore, if a user's password is set to expire in 90 days and they are 1 day away, all they have to do is lock their password and get it unlocked and they will have another 90 days using their current password.

I believe this could be a patch issue (missing one?) but I have been unable to track down a specific patch.

Any ideas/suggestions would be great.

Thanks

How do they get it unlocked? I would suggest that whomever is doing the unlock needs to do three things in order:-It may just be a procedural change. You can easily script these to give the people doing it just one command to run and mask off the other parts.



Does that help?


Robin

Thanks for the suggestion. The only problem is once the account becomes locked (i.e. 3 failed attempts, etc), the lastchg field is modified in the /etc/shadow file and I don't know when the password was last changed by the user. So if the user changed their password 5 days ago and then locks their account but they know the password, I don't want the user to have to change their password again. I would only want to unlock their account and the user should still have 85 days before their password expires next. However, using passwd -u to unlock their account modifies the lastchg field and then they have another 90 days.

I don't think using passwd -l or passwd -u should modify the lastchg field. This box was upgraded over the years from previous Solaris versions and I'm guessing a patch related to this may exist but I haven't been able to find it.

It's probably easiest just tell them that the policy has to be that way. If they request a new password or an unlock of an account then they are forced to pick a new one and you have control of the rules about complexity, history etc.

An alternate would be to intercept the passwd command and log every action on it. That might give you a history of when people last changed password.


Do either of these help?



Robin

You could also make daily backups of the shadow file (not recycling them until you have accumulated one file for each day of your password expiration period). Then you can look at the shadow entries for the user you're unlocking to determine their password change history. (I presume that you also get notification when accounts are locked and unlocked that you can use to determine, by elimination, when the password was last changed by the user.) But, of course, if someone changed their password, forgot it, and was locked out trying to get back in all in one day, this won't catch that...