Trusted HP/UX to Redhat user conversion?

[rmueller58]

We will be migrating from HP/UX to Redhat EL 5 next year.. I need to figure out how best to convert several items..

1. Users - currently we are on a trusted HP/UX.

I've been told I can grab the /etc/shadows on the HP box, but on the trusted system the /etc/shadow does not exist.

What are the issues related to untrusting the system, capturing the shadow, then re-trusting the box?

secondly is any one aware of how to use PWCONV? how clean is it?

I'd want to do something similar for groups..

Any ideas appreciated.

[Tim Nelson · Accepted solution]

1) user migration can be done by simply parsing out the /etc/passwd and using that as input to a script on Linux.

2) You may be able to grab the encrypted passwd field from /tcb/files/auth/[aA-zZ]/username, but you will need to test this.

3) yes you can unconvert trusted ( beware that additional features, perhaps long passwords, may get lost )

4) The group file should be a no brainer. append relevant /etc/group entries into /etc/group on linux.

[rmueller58]

Tim,
Thanks, I may have to take the risk with the loss of a few passwords. I am sure I will have a few hiccoughs.. I will see what it looks like to pull the /tcb/auth/files directory and script a recursive useradd ... i believe I'd need to decrypt the passwd prior to doing a -stdin for password creation.. any thoughts on that?

[Bill Hassell]

> Thanks, I may have to take the risk with the loss of a few passwords. I am sure I will have a few hiccoughs.. I will see what it looks like to pull the /tcb/auth/files directory and script a recursive useradd ...

The /etc/passwd file will be your template to walk through the users. To obtain the encrypted password from /tcb, you extract the first letter of the user name to use as the directory: /tcb/files/auth/<1CHR>/userid. In that file, you'll see the encrypted password.

> i believe I'd need to decrypt the passwd prior to doing a -stdin for password creation.. any thoughts on that?

Won't work. Unix passwords cannot be decrypted as they are a lossy hash. However, the hash method uses crypt() so it should be portable to Linux, but test first. The exception will be for users that have passwords longer than 8 characters. For 8 chars or less, the password field will always be exactly 13 characters. Beyond 8 chars for a password, the field is longer and requires bigcrypt() which is an HP feature. The 13 char password fields should port to Linux but test first.

pwconv only updates the /tcb files and does not decode /tcb information.

[Heironimus]

HP-UX trusted systems support long (over 8 characters) passwords hashed using "bigcrypt". As I recall, passwords that are 8 characters or less have the same hash with bigcrypt as with crypt, so shorter passwords shouldn't cause problems moving to most UNIX systems.

That being said, I think the version of PAM that Red Hat ships claims to support bigcrypt, so you may be able to just use the hashes from /tcb as-is. If you don't want to stay with bigcrypt (nobody uses it on Linux) you can have PAM update the hash to md5 (or whatever) whenever people change their passwords.

Red Hat ships a version of useradd that can take the password hash on the command line, so you should not need to recover the original passwords.

[rmueller58]

Bill,

Thank you.
Perhaps you can tell me what is involved in untrusted the system and grabbing the shadow?

Our HP/Redhat accounting system VAR wants to do it with PWCONV..

[rmueller58]

Bill disregard my last post.. I just saw the last line of your post.

[Matti_Kurkela]

There is no way to decrypt a password, other than by brute force or a dictionary attack.

Even if RedHat has been configured to use MD5-hashed passwords, it will accept a traditional Unix-style password hash (8 or less password characters). The password will automatically be changed to MD5-hashed version next time the user changes his/her password. This compatibility mechanism *can* be disabled if you don't like it, but it is enabled by default.

To feed pre-encrypted passwords to RHEL, use the "chpasswd -e" command. Prepare a file with "username:encrypted_pass" pairs (one pair per line) and pipe the file to "chpasswd -e".

On RedHat, the chpasswd command will automatically put the encrypted password wherever it is supposed to go: if you are in "traditional unix style" mode, the password will go to /etc/passwd. If you have run pwconv (or specified "use shadow passwords" when installing RHEL), the passwords will automatically go to /etc/shadow.

MK

[Tim Nelson]

You should be able to simply paste the encrypted password into the proper field of either /etc/passwd or /etc/shadow. IDK if this would work cross-platform, will have to test it. (From hpux to hpux you can cut and paste the encrypted password)

[rmueller58]

Matt, that helps..

If I pull the u_pwd=:\
field and other pertinent information about the user from the /etc/passwd including userid, gid and other group membership, home-directory, from the HP/UX box, then pass through useradd and chpasswd in a do while or for loop.

I have a test box I am going to blow and see what happens.

Based on what I am gathering from all of you is avoid the PWCONV all together and script it.

[rmueller58]

I meant pulling pertinent info from /etc/passwd and /tcb/auth/file//username

[rmueller58]

maybe someone can tell me, are the passwords in tcb/auth/files MD5 or DES?

[Heironimus]

The password hashes under /tcb are actually bigcrypt, which is based on crypt, which is in turn based on DES. They're not really DES, but they're based on it.

[Matti_Kurkela]

If the password has 8 characters or less in its plaintext form, the encryption result of bigcrypt() is exactly the same as with the usual crypt().

When encrypting passwords of more than 8 characters, bigcrypt() chains the segments together.

RedHat Enterprise Linux does not have the equivalent of bigcrypt(). After reading the man page of bigcrypt(3C), I think it would be possible to truncate the encrypted password string to 12 characters (the standard size of crypt() encrypted output + salt) and feed it to the RHEL machine.

Then the users could be given the following work-around:
"If your password does not work in the RHEL machine, type in only the first 8 characters of your password when you log in the first time. Then use the 'passwd' command to change your password. After that, your long password will again work as usual."

MK

[rmueller58]

Guys,

I did get a convert script built..

The existing passwords did not convert.

I did get the users to convert.. I will probably just assign a password and force change on 1st login in when we convert.

I used the following command in my script, and assumed the encrypted password would be used..

echo useradd -c "$description" -g "$ggroup" -d "$upath" -s "$ushell" -p "$pass" $uname


I will try the chpasswd command in a script and see what occurs

[rmueller58]

passwords will be handled in a different fashion..