unable to change password

[benjamin_29]

I have a 10.20 running with OpenSSH_3.8p1. A user has an account locked due to password life time expire (ie. lockout flag '1000000'). After the account reactived (modprpw -k {account}), he tried to login again but failed.

hostname> ssh server2
user@server2's password:
Last login: Wed Jul 21 21:45:16 2004 from server1
WARNING: Your password has expired.
You must change your password now and login again!
Usage: passwd [ -F file ] [ name ]
Connection to server2 closed.

The user could not login to change the password. Anyone know how to resolve this?

[Simon Hargrave]

Do a /usr/lbin/modprpw -x {account}

This will generate a random pronouncable password for them. Then do a passwd -f, to force them to change it on next logon.

Give them the random password, and they can login.

[RAC_1]

After you unlocked the account, did you check it got unlocked successfully??

/usr/lbin/getprpw -m lockout "user_name"

It shoud return 00000, if not it has problems.

Anil

[benjamin_29]

The flag shows '0000000'. The user was kicked out immediately after entering the password.

We are trying not to use the password generator.

It seems that it was trying to invoke the 'passwd' command to force the user to change the password but failed to pass the username to the command.

[RAC_1]

As a root user, change the password and do passwd -f.

Let user login with the password that you set. He will be forced to change the password once he logs in.

Anil

[benjamin_29]

User could not login even resetting the password. It showed the same message after entered the new password

[RAC_1]

Try a plain telnet to box and check. Check if it gives any errors.

Anil

[Jack C. Mahaffey]

Using trusted security? If yes, cd to /tcb/files/auth/
and see if there more than one login entry for this user with an extension. I've had a problem before where there was a duplicate login file with the extention '_t' I believe.

We don't use ssh, however.

[Brian Markus]

I'm going to give you an example of how to reset a user's password by editing a file.
cd /tcb/files/auth/b (swap b with the letter that your user's login starts with)
edit the file in that directory with that persons name. for example in my case

vi /tcb/files/auth/b/bmarkus


bmarkus:u_name=bmarkus:u_id#1234:\
:u_pwd=aBcDeFG1a2b3c4:\
:u_bootauth:u_auditid#4321:\
:u_auditflag#1:\
:u_minchg#0:u_exp#0:u_life#0:u_succhg#1012272085:\
:u_unsucchg#1089997903:u_llogin#0:u_pw_expire_warning#0:u_suclog#1092279891:\
:u_suctty=ttyp3:u_unsuclog#1092371050:u_unsuctty=ttyp3:u_numunsuclog#0:\
:u_maxtries#5:u_lock@:chkent:



Remove the hash from the :u_pwd=:\ The user should have no password after doing this.

I wonder how many people are going to run crack against that fake hash :) hehe.


If this file some how got an odd character in it, it will have problems. Another thing to try is the following: Backup the file, then take a known good user's file and copy it in place.
Then change the u_id# etc...

Another possible issue is having a duplicate u_id on the system. Check every directory in /tcb/files/auth/* for a file with a dupe u_id.

If all else fails, remove the user and re-add them.

Hope this helps.

-Brian.

[benjamin_29]

Thx for your help.

We have isolated the source of the problem. When root account forces the password change (ie. passwd -f $username), user cannot login even the account is not locked. It happen after we upgraded the SSH to 3.8p1. A workaround solution is to reset the users password without forcing them to change it.

[Massimo Bianchi]

Hi,
since you mentioned SSH 3.8p1,
i suggest you to have a look at the PAM paragraph, maybe you have choosen not to use it. WIth Trusted system, this may lead to strange behaviour.

HTH,
Massimo