How to find the last password change date in HP

[binraj]

Hi
How do we find the date of last password change in HP.
If someone knows this for Solaris also, please let me know.

Thanks

[harry d brown jr]

Is the system trusted?? IE /tcb exists ??

are you using nis, nis+, ldap, ... ???

live free or die
harry

[Ravi_8]

Hi,

Unless the system is trusted, you can't find this.

[thewho?]

Hello,
If it's a trusted system, try
/usr/lbin/getprpw -r -m spwchg


HTH,
Luis

[Darrell Allen]

Hi,

HP "trusted systems" provide much more info and flexibility for such issues.

You can crudely calculate to within a week when the password was changed on an HPUX system that has not converted to a trusted system as long as you utilize password aging. Here's an excerpt from "man 4 passwd":


The encrypted password consists of 13 characters chosen from a 64-
character set of "digits" described below, except when the password is
null, in which case the encrypted password is also null. Login can be
prevented by entering in the password field a character that is not
part of the set of digits (such as *).

The characters used to represent "digits" are . for 0, / for 1, 0
through 9 for 2 through 11, A through Z for 12 through 37, and a
through z for 38 through 63.

Password aging is put in effect for a particular user if his encrypted
password in the password file is followed by a comma and a nonnull
string of characters from the above alphabet. (Such a string must be
introduced in the first instance by a superuser.) This string defines
the "age" needed to implement password aging.

The first character of the age, M, denotes the maximum number of weeks
for which a password is valid. A user who attempts to login after his
password has expired is forced to supply a new one. The next
character, m, denotes the minimum period in weeks that must expire
before the password can be changed. The remaining characters define
the week (counted from the beginning of 1970) when the password was
last changed (a null string is equivalent to zero). M and m have
numerical values in the range 0 through 63 that correspond to the 64-
character set of "digits" shown above. If m = M = 0 (derived from the
string . or ..), the user is forced to change his password next time
he logs in (and the "age" disappears from his entry in the password
file). If m > M (signified, for example, by the string ./), then only
a superuser (not the user) can change the password. Not allowing the
user to ever change the password is discouraged, especially on a
trusted system.

Trusted systems support password aging and password generation. For
more information on converting to trusted system and on password, see
Managing Systems and Workgroups and sam(1M).



Consider the following passwd file entry from a non-trusted system using password aging for userA that just changed his password today:
userA:1234567890123,6/hO:117:20:UserA,,,:/home/userA:/usr/bin/sh

The 4 characters in the password field after the comma are "6/hO". From the man page info we can derive:

6 = max 8 weeks that password is valid
/ = miminum 1 week between password changes
hO represents the password was changed this number of weeks since the beginning of 1970. In this case, it's 1709 weeks.

To convert hO (that's a capital "O"), you have to convert from base 64 to base 10. You also have to figure out from the man page info that h is 45 and O is 26. Also note the digits are read from right to left. I derived that because the entry for a user whose password I changed 2 weeks ago is "fO". Plus, the formula I use below wouldn't work otherwise.

The formula I used was found at (heck, I ain't smart enough to know this stuff): http://www.poof.ca/base10.html

So basically you come up with:
((64 to the 1st power)*26) + ((64 to the 0 power)*45)
= 1664+45
=1709

Lastly, note that Jan 1, 1970 was on a Thursday so the number of weeks increments every Thursday. hO will be the value placed in the passwd entry from today thru next Wednesday. Next Thursday, the value will be iO.

Darrell

[binraj]

Thanks to every one who have replied. Mine is a trusted system and the command what Luis has given worked fine. Thanks to Darrell also for the details.
Do you know how we can get it done on Solaris.

Thanks

[Glenn S. Davidson]

I use passwd -as. I've also used it on HP but it doesn't seem to be as reliable. In /etc/shadow you have a standard comma delimited file. The entries are as stated (I'm going from memory here)
login:password:date changed:minimum change days:max change days:# warning days:expiration date

The date changed corresponds to the number of days since 1/1/1970 (actually 12/31/69) for today it could be 11960 (or something like that)

Minimum change days is how many days must transpire before you can change the password again.

Maximum change days is how many days that password is good for.

# warning days is how many days in advance you will be warned before your password expires. This is interesting since there is no actual notification that occurs.

Expiration date is the drop dead date that the account will be locked. Usually used for contractors and such. I've never actually used this so I can't tell if it works. As far as I know there is no inherent way for Solaris to "lock" an account.

Hope this helps!

Glenn

[Glenn S. Davidson]

OK, so I wanted to be a little more helpfull and I decided to boot up my workstation. Here is some examples:

/etc/shadow:
user1:::1:45:7:60::
user2:xxxxxxxxxxxxx:11990:1:45:7:60::

This shows user1 set up with password expiration but never having logged in. The 2 empty fields would be the password entry and the expiration date respectively.

The second entry shows user2 having logged in and set a password that will expire 11990 days after 12/31/69. which would be 10/30/02.

These entries show that the users have to wait 1 day before trying to change their password again. That the password is good for 45 days and they will start receiving warning messages 7 days prior to the expiration date.

passwd -as shows the following for the same users:

user1 NP 12/31/69 1 45 7
user2 PS 10/30/02 1 45 7

NP means that there is no password assigned. PS means that there is a password assigned. The third option you would see is LK meaning the account is locked.

Some Solaris problems:
There really is no notification of the expiration date coming up.

When the account expires there is no automatic locking of accounts.

There is no way to specify or track password history depth (i.e. how often you can re-use the same password)

Password construction is very limited.

There is no automated way to lock an account if someone doesn't know the password (you could try all day long).

There is a way to specify and log the number of failed retries.

Let me know if there is anything else you need to know. I have looked into this recently (as you might be able to tell). I suppose I could be happy that HP does a better job but also sad that Sun doesn't feel these things are important enough to address.

Glenn

[Glenn S. Davidson]

Well, I should have let you know that I'm not as smart as I sounded. The 11990 specified in the example is the actual date that the password was changed (10/30/02). In the example 45 would be added to that number by the system to determine the expiration date.

Sorry for the confusion.

Glenn