Encrypted passwords on trusted systems

[Mel Burslan]

Hello everyone,

I am having difficulty understanding how the encrypted passwords work in the trusted computing environment under 11i.

In the old untrusted days, I used to issue a massive search and replace script on remote hosts, with the encoded password and the users' passwords were set at once.

Right now, I am trying to do the same thing, i.e., using passwd command on the management node, which is also trusted, on a dummy user name, and getting the encrypted password from /tcb/files/auth/d/dummy and I am down to pasting it to one single user's auth file and it still does not work with the same string of characters typed as the password.

Could somebody please enlighten me what I am missing here ? Is the password hash related to the username or under which auth directory it sits or anything like that ?

More importantly, if it were you, how would you do a massive password reset of many, many users on several trusted systems from one master node without resorting to expect utility. Initial passwords are the same for everyone, so, one encrypted string should suffice I assume.

Thanks for all the help in advance.

[RAC_1]

What command you use to generate the encrypted password?? Have you tried /usr/lbin/makekey??

Also when you are pasting it, are doing it correctly??

Anil

[Steven E. Protter]

I don't think the encryption of passwords changed when you went trusted.

The location was scattered among the /tcb/files/auth folder.

the passwd -sa command works the same for example.

With Linux systems I've always been able to copy the /etc/shadow records from one system to another and the users passwords works right on the second system.

Never been able to do that with HP-UX (more secure?). I've always had to set up temporary passwords, force a change on next login and communicate with the users.

SEP

[Mel Burslan]

I did not use makekey explicitly. I created a dummy user and set password to this string I want as initial password to all my new users. So, I copied the encrypted password string from the dummy user's auth file.

[Mel Burslan]

SEP: this is exactly my dilemma. I do not want to create temporary passwords interactively for 50+ users on 12 new systems. All of these systems are accesible as root, via ssh, from a sigle management host. I want to issue my command(s) from the mgmt host and be done with it.

[John Kittel]

I asked a similar question once and got several good answers. Here is the link:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=214045

I have used the c function, crypt, as desribed in one of the posts to that thread, to generate passwords, and then put it into the tcb using the SAM routine, /usr/sam/lbin/usermod.sam, also described in that thread. Rajeev Shukla gets credit for that.

Also, I have been able to propagate passwords to other systems ( SG nodes in my case), by copying the user's tcb file, but I gather that will not work for you. Perhaps you can find a way to get the usermod.sam method to work remotely, or find out how it works and duplicate that...

- John

[Sridhar Bhaskarla · Accepted solution]

Hi Mel,

Make sure that the account is not locked. Run
'getprpw -m lockout ' and see if you get all zeroes in the output. If it is locked unlock the account using 'modprpw -k '.

usermod.sam is a good idea. One of the issues with it is that it may fail if the user is active on the boxes. This is mostly true with application accounts. I would try 'usermod.sam' followed by 'modprpw -k' first. That should cover around 70-80% of the accounts based on the activity of the system. Rest of them are to be fixed using 'sed'. But it is not a good idea to manually edit the password files. You will have to ensure that there is no other account related activity while doing the 'sed' action.

-Sri

[Sundar_7]

Mel,

Passwords are encrypted in the same way in both trusted and non-trusted systems.

the only difference being that, crypt() is used to create the hashed passswords in non-trusted system and bigcrypt() in trusted systems.

crypt() can only take 8 characters as the password. So trusted system uses bigcrypt() to create the hashed passwords. bigcrypt() can take in more than 8 characters as input.

But both crypt() and bigcrypt() uses the first two characters as salt.

This is how it works

1) User enters the password
2) login gets the encrypted password from /etc/passwd or from /tcb/files/auth/ directory (or from other sources)
3) Takes out the first 2 characters of the encrypted password and passes the password keyed in by the user to crypt() or bigcrypt() and compares the output from *crypt() with the encrypted password it got from the system
4) If both matches, the system lets the user login.

One more thing: As mentioned above by Sri, the default behaviour of usermod.sam is to exit with error code 8 if the user is currently logged in.

But you can use the undocumented -F option with usermod.sam. if you use the -F option, usermod.sam will change the password of the user even if the user is currently logged in.

Hope this helps

- Sundar

[Mel Burslan]

Thanks for all of the answers. In the light of these facts, I have written a piece of shell script in the tune of :

HASHSEED=`date +%S`
ENCPASS=`echo "temppass"${HASHSEED}|/usr/lib/makekey`
dirn=`echo $USERID | cut -c1`
cd /tcb/files/auth/${dirn}
l=`grep -n u_pwd $USERID | cut -d: -f1`

sed -e ${l}s+:u_pwd=\*+:u_pwd=${ENCPASS}+ $USERID > /tmp/eraseme
cat /tmp/eraseme > /tcb/files/auth/${dirn}/${USERID}
sed -e ${l}s/\*:/:/ $USERID > /tmp/eraseme
cat /tmp/eraseme > /tcb/files/auth/${dirn}/${USERID}

sleep 1
/usr/sbin/pwconv
/usr/bin/passwd -f $USERID


and it seems to be working under the limited number of sample users I asked to test their new logins.

Thanks for the help.

[Mel Burslan]

Thanks for all the responses again.