1833749 Members
2655 Online
110063 Solutions
New Discussion

Re: Test Passwd Aging.

 
david_252
Frequent Advisor

Test Passwd Aging.

Team:

We want to test the passwd aging on 10.20 and 11.0 servers. when i do
passwd -x 0 it see an entry ZP after the comma on the passswd file, but i thought this command would immeditely effect the aging since i mentioned 0. But it did not work. So, how do I effect a passwd aging in the command line so that it would age the passwd immeditely? also, any change in the command for an NIS environment?

Thanks

David.
4 REPLIES 4
Mark Grant
Honored Contributor

Re: Test Passwd Aging.

standard way of doing this is "passwd -f user" or adding ",M0" at the end of the encrypted password in the users /etc/passwd entry.

THe latter of these will definately work with NIS but I'm not sure about the former.
Never preceed any demonstration with anything more predictive than "watch this"
Umapathy S
Honored Contributor

Re: Test Passwd Aging.

David,
As Mark has said, when creating new logins the passwd -f forces the user to change the default passwd to his won. We use that. It works for NIS also.
The min and max stuff are rolled over to the nearest possible week. So, I think it will take atleast one week to force change users passwd.

HTH,
Umapathy
Arise Awake and Stop NOT till the goal is Reached!
Steven E. Protter
Exalted Contributor

Re: Test Passwd Aging.

After implementing aging with a non-zero number, roll the system date forward. Don't do this on a production system.

Then log in with the user, see that it works and roll back the system date.

Or take my word for it, we've been using it for years on 11.00 systems and before that 10.20 ones.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
doug hosking
Esteemed Contributor

Re: Test Passwd Aging.

Umapathy S raises an important point that often causes confusion. The standard expiration info is keep in weeks. To add confusion, the week starts on Thursday!
Why Thursday? Because the dawn of UNIX time (January 1, 1970) was a Thursday. This is not obvious to the casual observer and has frequently caused confusion. As a practical matter this isn't a big deal unless your password expiration policy requires VERY frequent password changes. In the worst case it means passwords are valid for a fraction of a week longer than expected.

Trusted mode configurations keep time stamps for expiration and other things in units of seconds since the epoch, rather than in weeks, which removes this confusion. But that's not going to help you if you need something compatible with NIS.