Migrating from Tru64 to Solaris 10
Jim McCullars
enhanced security) to a Sun machine running Solaris 10. Is there a way to do
this without forcing all users to get a new password? On the Tru64 machine, I
can run edauth to get the encrypted password string, but pasting this into
/etc/shadow on the Solaris box does not preserve the password like I expected
it would. Can this be done? Thanks...
Jim McCullars
University of Alabama in Huntsville
Rodrick Brown
"Jim McCullars" <j...@info2.uah.edu> wrote in message
news:dl0hmf$c5t$1...@info2.uah.edu...
/etc/shadow only stores the hashes of your password not the actuall string,
depending on what format Tru64 stores its passwords it may or may not be
compatible.
--
Rodrick R. Brown
Senior IT Consultant
http://www.rodrickbrown.com
rodrick.brown[<@>]gmail.com
When in 1986 Apple bought a Cray X-MP and announced that they would use it
to design the next Apple Macintosh, Seymour Cray replied, "This is very
interesting because I am using an Apple Macintosh to design the Cray-2
supercomputer."
Casper H.S. Dik
>Hi, we are planning to migrate our campus email server from Tru64 (with
>enhanced security) to a Sun machine running Solaris 10. Is there a way to do
>this without forcing all users to get a new password? On the Tru64 machine, I
>can run edauth to get the encrypted password string, but pasting this into
>/etc/shadow on the Solaris box does not preserve the password like I expected
>it would. Can this be done? Thanks...
What type of encrypted passwords are these? It almost sounds like
they're not normal Unix crypt passowrds.
It appears from perusing some of the google hits that tru64 supports
three types of encryption:
- standard unix crypt (13 characters in length, from [a-zA-Z0-9/.])
- bigcrypt which looks like it's a perturbation of stdcrypt.
- crypt16 of which I cannot find the definition off-hand.
So it depends somewhat on which encryption mechanism you use.
You can then write your own Solaris plugin and then modify the
encrypted passwords so they have a $tru64$ prefix (in case that is
how you name your prefix).
Such a module would certainly be appreciated by more Tru64 admins.
How to write such modules is documented and the sample source can
be found at:
which is where you'll find the Solaris source code.
Casper (who co invented the Solaris pluggable crypt)
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Oscar del Rio
> Hi, we are planning to migrate our campus email server from Tru64 (with
> enhanced security) to a Sun machine running Solaris 10. Is there a way to do
> this without forcing all users to get a new password? On the Tru64 machine, I
> can run edauth to get the encrypted password string, but pasting this into
> /etc/shadow on the Solaris box does not preserve the password like I expected
> it would. Can this be done? Thanks...
Password encryptions supported in Solaris 10:
Casper H.S. Dik
>http://docs.sun.com/app/docs/doc/816-4557/6maosrjbj?a=view
But you can roll your own :-)
Generally, you should be able to migrate any encryption string to
Solaris provided it meets the following criteria:
- the password is shorter than 255 characters
- you know the algorithm to verify the passwords, if you
are given the username, clear text password and the hash.
all it takes is writing the plugin and installing them.
(And generally you will need to add a prefix to each encrypted password
string)
Casper
Jim McCullars
: j...@info2.uah.edu (Jim McCullars) writes:
: >Hi, we are planning to migrate our campus email server from Tru64 (with
: >enhanced security) to a Sun machine running Solaris 10. Is there a way to do
: >this without forcing all users to get a new password? On the Tru64 machine, I
: >can run edauth to get the encrypted password string, but pasting this into
: >/etc/shadow on the Solaris box does not preserve the password like I expected
: >it would. Can this be done? Thanks...
: What type of encrypted passwords are these? It almost sounds like
: they're not normal Unix crypt passowrds.
They aren't. As you discovered, there are several algorithms supported
under Tru64 Enhanced Security. They also use a database to store security-
related attributes about each user who is in the /etc/passwd file. One of
the fields can tell the system that future password changes will be stored
using the regular crypt algorithm. What I had planned to do was change this
for each user, then announce that everyone needs to change his password, but I
ran into another snag. If you do that, then the Tru64 passwd program will not
allow passwords longer than 8 characters. Plus, the poppassd server (that
allows POP users without a login shell to change their passwords) doesn't seem
to work properly if the current password is longer than 8 characters. Bummer.
This was going to be so easy. Famous last words, right?
Matt McLeod
> This was going to be so easy. Famous last words, right?
I believe we did it by writing a small module to run from
whatsitsname -- the Tru64 equivalent of PAM, it's been ages
since I had to care -- which saved the plaintext password
off to the side. We did it that way because we were moving
to Cyrus and wanted to use strong auth, but you could quite
reasonably compute a Solaris-compatible crypt string and
store that instead.
Matt
John D Groenveld
Casper H.S. Dik <Caspe...@Sun.COM> wrote:
>Such a module would certainly be appreciated by more Tru64 admins.
Might also be appreciated or even already written by Anil Gadre and
company's HP-Away marketing wonks.
The OP should ask the Sun sales critter if Doug Wilson has any
resources for him.
John
groe...@acm.org
Casper H.S. Dik
Give me the specs, some sample encryption/password combinations
and I'll write it (if the crypto code derives from something known)
Casper
Jim McCullars
: >The OP should ask the Sun sales critter if Doug Wilson has any
: >resources for him.
: Give me the specs, some sample encryption/password combinations
: and I'll write it (if the crypto code derives from something known)
I've tried to find some specs on the Tru64 crypt16 function to no avail.
All I can find is this, from the crypt man page:
The crypt() subroutine is the password encryption routine.
It is based on the NBS Data Encryption Standard, with
variations intended to frustrate use of hardware implementations
of the DES for key search.
The first argument to crypt() is normally a user's typed
password. The second is a 2-character string chosen from
the set [a-zA-Z0-9./]. The salt string is used to perturb
the DES algorithm in one of 4096 different ways, after
which the password is used as the key to encrypt repeatedly
a constant string. The returned value points to the
encrypted password, in the same alphabet as the salt. The
first two characters are the salt itself.
The crypt16() subroutine is identical to the crypt() function
except that it will accept a password up to sixteen
characters in length. It generates a longer encrypted
password for use with enhanced security features.
However, nothing that I can find doing a Google search documents exactly
how the routine works. I found a "Tru64 Security Programming" manual on HP's
web site, but the examples all seem to make use of library calls.
Since Tru64 was originally based on OSF/1, I wonder if source code is
available somewhere? Or maybe the Enhanced Security stuff was a DEC add-on to
OSF/1? I don't know. But if anyone can find specs, I would be more than
happy to send some clear-text passwords and the associated encrypted strings.
Rolf Blom
If you only need to recreate the user accounts &passwords,
why not have the Solaris machine as a login frontend for the Tru64 box,
either capture users/pwd:s and then recreate these as solaris accounts
for next login,
(or just create new user accounts with expired passwords, to force a change)
doing this once for each user as s/he logs in?
Granted, it may take some time until all users are transferred.
Maybe you need to use the old passwords for decrypting files or file
xfer as well, I don't know.
Kind of a hack approach, I know...but perhaps useable in case no other
option is available.
Has to be sanity checked of course, I may be far out on a limb here.
/Rolf
Casper H.S. Dik
> I've tried to find some specs on the Tru64 crypt16 function to no avail.
>All I can find is this, from the crypt man page:
> The crypt() subroutine is the password encryption routine.
> It is based on the NBS Data Encryption Standard, with
> variations intended to frustrate use of hardware implementations
> of the DES for key search.
> The first argument to crypt() is normally a user's typed
> password. The second is a 2-character string chosen from
> the set [a-zA-Z0-9./]. The salt string is used to perturb
> the DES algorithm in one of 4096 different ways, after
> which the password is used as the key to encrypt repeatedly
> a constant string. The returned value points to the
> encrypted password, in the same alphabet as the salt. The
> first two characters are the salt itself.
> The crypt16() subroutine is identical to the crypt() function
> except that it will accept a password up to sixteen
> characters in length. It generates a longer encrypted
> password for use with enhanced security features.
Can you produce some sample output?
(Say for passwords "a", "aa" etc upto 16 "a"s)
for both encryptions (with a fixed SALT)
hubcap
than on any of the other systems I was looking at (solaris, hpux, bsd,
linux, aix...)
-Mike
Jim McCullars
: > I've tried to find some specs on the Tru64 crypt16 function to no avail.
: >All I can find is this, from the crypt man page:
<snip>
: > The crypt16() subroutine is identical to the crypt() function
: > except that it will accept a password up to sixteen
: > characters in length. It generates a longer encrypted
: > password for use with enhanced security features.
: Can you produce some sample output?
: (Say for passwords "a", "aa" etc upto 16 "a"s)
: for both encryptions (with a fixed SALT)
Yes, here you go:
bash# cat crypt-test.c
main(int argc, char *argv[]) {
puts(crypt("a", "00"));
puts(crypt("aa", "00"));
puts(crypt("aaa", "00"));
puts(crypt("aaaa", "00"));
puts(crypt("aaaaa", "00"));
puts(crypt("aaaaaa", "00"));
puts(crypt("aaaaaaa", "00"));
puts(crypt("aaaaaaaa", "00"));
puts(crypt("aaaaaaaaa", "00"));
puts(crypt("aaaaaaaaaa", "00"));
puts(crypt("aaaaaaaaaaa", "00"));
puts(crypt("aaaaaaaaaaaa", "00"));
puts(crypt("aaaaaaaaaaaaa", "00"));
puts(crypt("aaaaaaaaaaaaaa", "00"));
puts(crypt("aaaaaaaaaaaaaaa", "00"));
puts(crypt("aaaaaaaaaaaaaaaa", "00"));
}
bash# ./crypt-test
00KD3xBhymZK2
00c9YEk5sg7xs
00If2JpXtjyy6
00BX8JrbYbyco
00dBTYb3sJPLc
00xLpqdiVGV6w
00qLaBLPFiQ2E
00g0qqaURJS2.
00g0qqaURJS2.
00g0qqaURJS2.
00g0qqaURJS2.
00g0qqaURJS2.
00g0qqaURJS2.
00g0qqaURJS2.
00g0qqaURJS2.
00g0qqaURJS2.
bash# cat crypt16-test.c
main(int argc, char *argv[]) {
puts(crypt16("a", "00"));
puts(crypt16("aa", "00"));
puts(crypt16("aaa", "00"));
puts(crypt16("aaaa", "00"));
puts(crypt16("aaaaa", "00"));
puts(crypt16("aaaaaa", "00"));
puts(crypt16("aaaaaaa", "00"));
puts(crypt16("aaaaaaaa", "00"));
puts(crypt16("aaaaaaaaa", "00"));
puts(crypt16("aaaaaaaaaa", "00"));
puts(crypt16("aaaaaaaaaaa", "00"));
puts(crypt16("aaaaaaaaaaaa", "00"));
puts(crypt16("aaaaaaaaaaaaa", "00"));
puts(crypt16("aaaaaaaaaaaaaa", "00"));
puts(crypt16("aaaaaaaaaaaaaaa", "00"));
puts(crypt16("aaaaaaaaaaaaaaaa", "00"));
}
bash# ./crypt16-test
00YsziGoi9ktAas1wm0AZG56
00eafTydjgjOIas1wm0AZG56
00xYzPu7Ms4Ugas1wm0AZG56
00Z5QMI174Lvoas1wm0AZG56
00Avqitb3SeHwas1wm0AZG56
008JBFm.A3YP2as1wm0AZG56
007sCeftCGjkUas1wm0AZG56
00xHEaqmZTJXEas1wm0AZG56
00xHEaqmZTJXEPvxSVjF8I7Y
00xHEaqmZTJXE95bPVfmrVmQ
00xHEaqmZTJXEjMMVCEcJrag
00xHEaqmZTJXEbgk0cGXHjXY
00xHEaqmZTJXEDEPp80coKIU
00xHEaqmZTJXEIPS/2XwKZkc
00xHEaqmZTJXE6aN3Ssytojc
00xHEaqmZTJXEKhr/qzEcMK6
Casper H.S. Dik
>: (Say for passwords "a", "aa" etc upto 16 "a"s)
Coult you try the empty password too?
>bash# ./crypt16-test
>00YsziGoi9ktAas1wm0AZG56
This is apparently the concatenation of 20 rounds perturbed
DES for the first 8 characters combined with 5 rounds of DES
for the second (the standard crypt uses 25 rounds).
Could you try this for bigcrypt too? Which encryption are
you using? This particular form of crypt is actuall *less*
secure than standard crypt.
With some coding, I got:
len password crypt crypt16 bigcrypt?
0 00as1wm0AZG56 00...........as1wm0AZG56 00as1wm0AZG56
1 a 00KD3xBhymZK2 00YsziGoi9ktAas1wm0AZG56 00KD3xBhymZK2
2 aa 00c9YEk5sg7xs 00eafTydjgjOIas1wm0AZG56 00c9YEk5sg7xs
3 aaa 00If2JpXtjyy6 00xYzPu7Ms4Ugas1wm0AZG56 00If2JpXtjyy6
4 aaaa 00BX8JrbYbyco 00Z5QMI174Lvoas1wm0AZG56 00BX8JrbYbyco
5 aaaaa 00dBTYb3sJPLc 00Avqitb3SeHwas1wm0AZG56 00dBTYb3sJPLc
6 aaaaaa 00xLpqdiVGV6w 008JBFm.A3YP2as1wm0AZG56 00xLpqdiVGV6w
7 aaaaaaa 00qLaBLPFiQ2E 007sCeftCGjkUas1wm0AZG56 00qLaBLPFiQ2E
8 aaaaaaaa 00g0qqaURJS2. 00xHEaqmZTJXEas1wm0AZG56 00g0qqaURJS2.
9 aaaaaaaaa 00g0qqaURJS2. 00xHEaqmZTJXEPvxSVjF8I7Y 00g0qqaURJS2.Hoo52n9FY5M
10 aaaaaaaaaa 00g0qqaURJS2. 00xHEaqmZTJXE95bPVfmrVmQ 00g0qqaURJS2.p18rniWBw/s
11 aaaaaaaaaaa 00g0qqaURJS2. 00xHEaqmZTJXEjMMVCEcJrag 00g0qqaURJS2.0mGBww7BCpY
12 aaaaaaaaaaaa 00g0qqaURJS2. 00xHEaqmZTJXEbgk0cGXHjXY 00g0qqaURJS2.984AEoQ7eNs
13 aaaaaaaaaaaaa 00g0qqaURJS2. 00xHEaqmZTJXEDEPp80coKIU 00g0qqaURJS2.T7pPni.QJT.
14 aaaaaaaaaaaaaa 00g0qqaURJS2. 00xHEaqmZTJXEIPS/2XwKZkc 00g0qqaURJS2.R9nPyKoKUMA
15 aaaaaaaaaaaaaaa 00g0qqaURJS2. 00xHEaqmZTJXE6aN3Ssytojc 00g0qqaURJS2.A9smuvNJuP2
16 aaaaaaaaaaaaaaaa 00g0qqaURJS2. 00xHEaqmZTJXEKhr/qzEcMK6 00g0qqaURJS2.iKE66hxIZvE
17 aaaaaaaaaaaaaaaaa 00g0qqaURJS2. 00xHEaqmZTJXEKhr/qzEcMK6 00g0qqaURJS2.iKE66hxIZvEByHvQhpx/mg
18 aaaaaaaaaaaaaaaaaa 00g0qqaURJS2. 00xHEaqmZTJXEKhr/qzEcMK6 00g0qqaURJS2.iKE66hxIZvEMBbT1gyTMlU
19 aaaaaaaaaaaaaaaaaaa 00g0qqaURJS2. 00xHEaqmZTJXEKhr/qzEcMK6 00g0qqaURJS2.iKE66hxIZvEVVoR5LDE31c
20 aaaaaaaaaaaaaaaaaaaa 00g0qqaURJS2. 00xHEaqmZTJXEKhr/qzEcMK6 00g0qqaURJS2.iKE66hxIZvE.D9W24zRYso
21 aaaaaaaaaaaaaaaaaaaaa 00g0qqaURJS2. 00xHEaqmZTJXEKhr/qzEcMK6 00g0qqaURJS2.iKE66hxIZvER1uOkOLVLp.
22 aaaaaaaaaaaaaaaaaaaaaa 00g0qqaURJS2. 00xHEaqmZTJXEKhr/qzEcMK6 00g0qqaURJS2.iKE66hxIZvE9VeAxpjcAs6
23 aaaaaaaaaaaaaaaaaaaaaaa 00g0qqaURJS2. 00xHEaqmZTJXEKhr/qzEcMK6 00g0qqaURJS2.iKE66hxIZvEv.L9um25W5c
24 aaaaaaaaaaaaaaaaaaaaaaaa 00g0qqaURJS2. 00xHEaqmZTJXEKhr/qzEcMK6 00g0qqaURJS2.iKE66hxIZvEPKPnVDd/0LI
Casper
Jim McCullars
: >: (Say for passwords "a", "aa" etc upto 16 "a"s)
: Coult you try the empty password too?
Yes, here it is for crypt and crypt16:
bash# cat crypt-test.c
main(int argc, char *argv[]) {
puts(crypt("", "00"));
puts(crypt("a", "00"));
puts(crypt("aa", "00"));
puts(crypt("aaa", "00"));
puts(crypt("aaaa", "00"));
puts(crypt("aaaaa", "00"));
puts(crypt("aaaaaa", "00"));
puts(crypt("aaaaaaa", "00"));
puts(crypt("aaaaaaaa", "00"));
puts(crypt("aaaaaaaaa", "00"));
puts(crypt("aaaaaaaaaa", "00"));
puts(crypt("aaaaaaaaaaa", "00"));
puts(crypt("aaaaaaaaaaaa", "00"));
puts(crypt("aaaaaaaaaaaaa", "00"));
puts(crypt("aaaaaaaaaaaaaa", "00"));
puts(crypt("aaaaaaaaaaaaaaa", "00"));
puts(crypt("aaaaaaaaaaaaaaaa", "00"));
}
yields
bash# ./crypt-test
00as1wm0AZG56
00KD3xBhymZK2
00c9YEk5sg7xs
00If2JpXtjyy6
00BX8JrbYbyco
00dBTYb3sJPLc
00xLpqdiVGV6w
00qLaBLPFiQ2E
00g0qqaURJS2.
00g0qqaURJS2.
00g0qqaURJS2.
00g0qqaURJS2.
00g0qqaURJS2.
00g0qqaURJS2.
00g0qqaURJS2.
00g0qqaURJS2.
00g0qqaURJS2.
and
bash# cat crypt16-test.c
main(int argc, char *argv[]) {
puts(crypt16("", "00"));
puts(crypt16("a", "00"));
puts(crypt16("aa", "00"));
puts(crypt16("aaa", "00"));
puts(crypt16("aaaa", "00"));
puts(crypt16("aaaaa", "00"));
puts(crypt16("aaaaaa", "00"));
puts(crypt16("aaaaaaa", "00"));
puts(crypt16("aaaaaaaa", "00"));
puts(crypt16("aaaaaaaaa", "00"));
puts(crypt16("aaaaaaaaaa", "00"));
puts(crypt16("aaaaaaaaaaa", "00"));
puts(crypt16("aaaaaaaaaaaa", "00"));
puts(crypt16("aaaaaaaaaaaaa", "00"));
puts(crypt16("aaaaaaaaaaaaaa", "00"));
puts(crypt16("aaaaaaaaaaaaaaa", "00"));
puts(crypt16("aaaaaaaaaaaaaaaa", "00"));
}
yields
bash# ./crypt16-test
00...........as1wm0AZG56
00YsziGoi9ktAas1wm0AZG56
00eafTydjgjOIas1wm0AZG56
00xYzPu7Ms4Ugas1wm0AZG56
00Z5QMI174Lvoas1wm0AZG56
00Avqitb3SeHwas1wm0AZG56
008JBFm.A3YP2as1wm0AZG56
007sCeftCGjkUas1wm0AZG56
00xHEaqmZTJXEas1wm0AZG56
00xHEaqmZTJXEPvxSVjF8I7Y
00xHEaqmZTJXE95bPVfmrVmQ
00xHEaqmZTJXEjMMVCEcJrag
00xHEaqmZTJXEbgk0cGXHjXY
00xHEaqmZTJXEDEPp80coKIU
00xHEaqmZTJXEIPS/2XwKZkc
00xHEaqmZTJXE6aN3Ssytojc
00xHEaqmZTJXEKhr/qzEcMK6
: >bash# ./crypt16-test
: >00YsziGoi9ktAas1wm0AZG56
: Could you try this for bigcrypt too? Which encryption are
: you using? This particular form of crypt is actuall *less*
: secure than standard crypt.
Unfortunately, bigcrypt does not seem to be implemented as a user-callable
library function in Tru64 (from perusing the HP docs, it looks like it is a
function in HP-UX, but not in Tru64). As or which encryption we are using
now, it seems to be a hybrid of crypt and bigcrypt (depending on whether the
user has changed his password or not). The default is bigcrypt. The good
news is, even though I cannot call bigcrypt as a function, I can take one of
your values:
: With some coding, I got:
: len password crypt crypt16 bigcrypt?
<snip>
9 aaaaaaaaa 00g0qqaURJS2. 00xHEaqmZTJXEPvxSVjF8I7Y 00g0qqaURJS2.Hoo52n9FY5M
and manually plug the string "00g0qqaURJS2.Hoo52n9FY5M" into the auth database
and the password is indeed now "aaaaaaaaa". Does that help any?
Jim McCullars
Casper H.S. Dik
>and manually plug the string "00g0qqaURJS2.Hoo52n9FY5M" into the auth database
>and the password is indeed now "aaaaaaaaa". Does that help any?
Yep.
I've got two sample modules now for bigcrypt and crypt16 which should
allow you to port your tru64 password; the only requirement is that
you prefix the "crypt16" passwords with "$c16$" and the "bigcrypt"
passwords with "$bc$" in the password database.
(Contact me and I'll send the CDDL'ed source code off-line and
then you can play with it)
Casper