passwd change on a trusted system

[Wendy Herbst]

I recently converted to a trusted system HP UX 11. We chose the option to have our users reset their passwords every ninety days. When this time expires, some users are prompted to change their password and are first prompted to enter their old password before they can create a new one. For some of our users who are entering their correct old passwords, the system is not recognizing it and simply stating sorry. Has anyone come across this? I can't find the difference between their accounts and those who can successfully change their passwords.

[RAC_1]

After ninty days, account will get locked. For the users where you get "sorry" message, check the lockout parameter for those users.

/usr/lbin/getprpw -m lockout "user_name"
The output will be 7 didgit no. Decode it as follows.

To decode what is returned, note that the position (left to right) represents:

1 past password lifetime

2 past last login time

3 past absolute account lifetime

4 exceeding unsuccessful login attempts

5 password required and a null password

6 admin lock

7 password is a *

Unlock the account as /usr/lbin/modprpw -k "user_name"

Also to avoid this problem, you may look at setting a expiry warning. (expwarn). This would warn the users that in xx days, they password will expire and they should chnage it.

Anil

[Wendy Herbst]

Thanks for your reply but I must note that I do have a warning set up for to notify users 14 days before hand. We havae a menu option that allows the user to proactively change their password before the time expires. Even before the time has expired the system does not recognize their current password as the old one.

[Patrick Wallek]

Is this the first time after converting to trusted that users are changing their passwords?

If so, are the users that are having problems using password that are longer than 8 characters? If so, have them try entering just the first 8 characters and see if that helps.

[RAC_1]

Are you upto date on patches required for trusted system?? I will recommand to check four settings
exptm - expiry time
lftm - life time of user
expwarn - expiry warning
mintm - min. time between password change

If I understand trusted systems correctly, if lftm expires, then account is locked. For the user that have problem, the lftm gets past the setting and hence when they get password change prompt, even they put right password, "sorry message" is given because, the accoutn is locked.

When user gets this message, check his above four settings and lockout setting. If it locked, then unlock and ask user to check. Not it should not give sorry message.

Anil

[Wendy Herbst]

This is actually the second time they are changing their passwords. I initally thought the issue was due to the eight character requirement so when the users first came across this, I reset their passwords as root using sam. The issue however is now rearing it's ugly head again. My account is currently doing this and my password is seven characters.

[Patrick Wallek]

What does your /etc/nsswitch.conf file have for passwd? It should be:

passwd: files

If it isn't, try changing it to files and see if it helps.

Just keep in mind that this is a shot in the dark......

[Patrick Wallek]

Another thought I just had -- are there any special characters in the password that might be causing you problems? Things like @,#,!,$, etc?

[Wendy Herbst]

Actually yes! I did have a # character in the password. If I myself as the user initiated the password change, the system would not recognize my "old password". Today I came into work and My password officially expired. When the change was initated this way it did recognize my old password. Could there be something to who actually initiates the password change i.e. user vs root?
Thanks for all of your help!

[A. Clay Stephenson · Accepted solution]

You should never allow #'s in the plaintext version of the password (or login). The reason is that many initial gettydef entries (ie before the login completes) with define or default character erase character to '#'. This is a legacy from the days of hardcopy terminals so that rather than hitting the backspace key, you entered a '#' to indicate that the preceding character was to be ignored.

So 'Sec#ret' becomes 'Seret' when the login process sees it.