Question on Migration of /etc/passwd and Security

Hello:
Just wondering if wanted to migrate users from one host A to B, can I do the
following:
Append the /etc/passwd to /etc/passwd of host B?
What if i throw Shadowed passwd to it? will that work as well (given that
above given scenario will work)?
Being new to HP-UX I was thinking about if that's possible. If it works
that' really bad from sec. perspective I guess, because that means the
encryption does'nt follow the mathematical theory of encryption being
toatally random.
Appreciate your comments.
Vince

Hi Vince
> Just wondering if wanted to migrate users from one host A to B, can I do the
> following:
> Append the /etc/passwd to /etc/passwd of host B?
>
> What if i throw Shadowed passwd to it? will that work as well (given that
> above given scenario will work)?
HP-UX by standard does not use a shadowed passwd (The encrypted
passwords are in /etc/passwd - not in shadowpasswd). HP-UX provids also
a "trusted system" mode, which provides a C2 security, but this is not
the default installation mode.
If your system _is_ trusted, then first convert to an untrusted mode,
move the users and the recovert to trusted mode.
So in standard mode the migration of users should work as follows
Carefully compare /etc/passwd of host A and /etc/passwd of host: no
double UserID, no identical usernames with different UserIDs.
Do the same for /etc/group and perhaps for /etc/logingroup.
Then merge the both files.
Control the resulting files with the commands pwck and grpck
If the machines also have local home directories:
Create/move the home directories
Perhaps you also have to check the NFS-mountpoints of the home dirs
and/or the automounter configuration.
Florian

0

Florian

8/25/2004 10:47:09 AM

On 2004-08-25, V <ccc@caraudio.com> wrote:
> Being new to HP-UX I was thinking about if that's possible. If it works
> that' really bad from sec. perspective I guess, because that means the
> encryption does'nt follow the mathematical theory of encryption being
> toatally random.
When you drill down far enough, you'll find that there's really
no such thing as random in the computer world; however, that's
not really germane to your question.
The reason you can copy encrypted passwords from one system to
another and have it work is the same reason that you can log on
to the box in the first place.
When logging in, the system prompts you for a password. It then
encrypts the password you entered using the same "salt" as is
listed in the password for your account. If you use the same salt
to encrypt the same word twice, they will come out exactly the same.
In other words, the system has to have some way of encrypting your
supplied password to compare it against the stored one. The salt
is the first two characters of the encrypted password. Examine
crypt(3) for more details.
I've occasionally pondered that it might be possible to come up with
a second word that, when encrypted, results in the same string.
Obviously, I'm no mathmetician; however, the limited number of
resulting encrypted characters would seem to imply this is possible.
Since its never been done and not ever talked about to my knowledge,
that probably means that even if it is possible, it's so exceedingly
improbable as to make the earth rotating backward more likely...
Interesting thing to think about when you're at home in front of a
broken television set.
Doug
--
--------
Senior UNIX Admin
O'Leary Computer Enterprises
dkoleary@olearycomputers.com (w) 630-904-6098 (c) 630-248-2749
resume: http://www.olearycomputers.com/resume.html

0

Doug

8/25/2004 12:45:01 PM

Hi Doug
> however, the limited number of
> resulting encrypted characters would seem to imply this is possible.
> Since its never been done and not ever talked about to my knowledge,
> that probably means that even if it is possible, it's so exceedingly
> improbable as to make the earth rotating backward more likely...
> Interesting thing to think about when you're at home in front of a
> broken television set.
Indeed a nice thought (especially: when we rotate earth backward, will
the inversion of cyclones make butterflies fly backwards in China, and
what is backwards then); but the the only question that remains for me:
what the heck is a television set?
;-)
Florian

0

Florian

8/25/2004 1:34:20 PM

In article <9KRWc.52882$pTn.12957@news01.bloor.is.net.cable.rogers.com>,
V <ccc@caraudio.com> wrote:
>Just wondering if wanted to migrate users from one host A to B, can I do the
>following:
>
>Append the /etc/passwd to /etc/passwd of host B?
Yes. If you have duplicate login names or uids, there can be some minor
problems from those. You also need to copy the users' home directories
from host A to host B, or arrange to remote-mount them.
>What if i throw Shadowed passwd to it? will that work as well (given that
>above given scenario will work)?
A long time ago HP-UX used a non-standard shadow file. The method did
not work well for systems with many users. Their current "trusted
system" stores the shadow information in something resembling a
database. This works a lot better for systems with many users, but
I have not seen any other vendors using it. Too bad; it's actually
pretty clever and extensible to boot.
>Being new to HP-UX I was thinking about if that's possible. If it works
>that' really bad from sec. perspective I guess, because that means the
>encryption does'nt follow the mathematical theory of encryption being
>toatally random.
1. Passwords aren't encrypted; they are hashed. Small but crucial
difference. 2. If the encryption were totally random, how would you
do decryption? Randomness is required for certain aspects of encryption
but not for all.

0

whoward

8/25/2004 6:21:30 PM

Florian Anwander wrote:
> Hi Vince
>
>> Just wondering if wanted to migrate users from one host A to B, can I
>> do the
>> following:
>> Append the /etc/passwd to /etc/passwd of host B?
>>
>> What if i throw Shadowed passwd to it? will that work as well (given that
>> above given scenario will work)?
>
> HP-UX by standard does not use a shadowed passwd (The encrypted
> passwords are in /etc/passwd - not in shadowpasswd). HP-UX provids also
> a "trusted system" mode, which provides a C2 security, but this is not
> the default installation mode.
>
> If your system _is_ trusted, then first convert to an untrusted mode,
> move the users and the recovert to trusted mode.
>
> So in standard mode the migration of users should work as follows
>
> Carefully compare /etc/passwd of host A and /etc/passwd of host: no
> double UserID, no identical usernames with different UserIDs.
>
> Do the same for /etc/group and perhaps for /etc/logingroup.
>
> Then merge the both files.
>
> Control the resulting files with the commands pwck and grpck
>
> If the machines also have local home directories:
> Create/move the home directories
>
> Perhaps you also have to check the NFS-mountpoints of the home dirs
> and/or the automounter configuration.
>
> Florian
>
Its actually fairly easy to bring tcb over too. if you tar up the /tcb
dir, /etc/passwd and /etc/group from the old machine and then untar them
on the new one, run authck(1M). If it does not say anything about stuff
besides passwd aging, etc. you should be ok. You might have to move
pw_id_map out of the way and increase the # in maxaid if you use auditing.

0

Alan

8/26/2004 12:55:17 AM

Hi Alan
>> Carefully compare /etc/passwd of host A and /etc/passwd of host: no
>> double UserID, no identical usernames with different UserIDs.
> Its actually fairly easy to bring tcb over too. if you tar up the /tcb
> dir, /etc/passwd and /etc/group from the old machine and then untar them
> on the new one, run authck(1M). If it does not say anything about stuff
> besides passwd aging, etc. you should be ok. You might have to move
> pw_id_map out of the way and increase the # in maxaid if you use auditing.
Uurrgggs! Thats ugly trickin'; I never would like that, because the
corresponding files stay in the ownership of the wrong user and group IDs.
I would always(!) check mismatches or dopublematches manually, because I
might have to think over the ownership of files. Following I have to
think over a order how to chown the related files.
Florian
--
mail an "fanwander AT mnet MINUS online PUNKT de"

0

Florian

8/26/2004 8:22:33 AM

Florian Anwander wrote:
> Hi Alan
>
>>> Carefully compare /etc/passwd of host A and /etc/passwd of host: no
>>> double UserID, no identical usernames with different UserIDs.
>>
>> Its actually fairly easy to bring tcb over too. if you tar up the /tcb
>> dir, /etc/passwd and /etc/group from the old machine and then untar
>> them on the new one, run authck(1M). If it does not say anything about
>> stuff besides passwd aging, etc. you should be ok. You might have to
>> move pw_id_map out of the way and increase the # in maxaid if you use
>> auditing.
>
> Uurrgggs! Thats ugly trickin'; I never would like that, because the
> corresponding files stay in the ownership of the wrong user and group IDs.
>
> I would always(!) check mismatches or dopublematches manually, because I
> might have to think over the ownership of files. Following I have to
> think over a order how to chown the related files.
>
> Florian
>
Believe it or not it works! get rid of pw_id_map, run authck, check
homedirs and it works. sys owns tcb so you should be ok, if you get uid
errors then there is a mismatch, either not in tcb... or passwd.

0

Alan

8/28/2004 12:39:45 AM

Hi Alan
>> I would always(!) check mismatches or dopublematches manually, because
>> I might have to think over the ownership of files. Following I have to
>> think over a order how to chown the related files.
>>
>> Florian
>>
> Believe it or not it works!
Of course it works!
> get rid of pw_id_map, run authck, check
> homedirs and it works. sys owns tcb so you should be ok, if you get uid
> errors then there is a mismatch, either not in tcb... or passwd.
This is ok, but I am not thinking about, whether it works from the
technical point of view. My position is to look how human beeings think
and work. And if human beeings rely on that something works technically,
they stop to think.
Just an example I could watch in my time at the support center:
- admin joins two passwds by a quite tricky script (he was quite
proud of ...),
- oradm user gets the wrong userID,
- causes on of the largest shop-systems in Austria not to
sell for nearly three days,
- makes the stock exchange quotation go down.
- very unlucky Ex-admin
Sorry for my unconvenient opinion, but scripts and automatisms make
people stop thinking too often.
Florian

0

Florian

8/30/2004 9:09:21 AM

Florian Anwander wrote:
> Hi Alan
>
>>> I would always(!) check mismatches or dopublematches manually,
>>> because I might have to think over the ownership of files. Following
>>> I have to think over a order how to chown the related files.
>>>
>>> Florian
>>>
>> Believe it or not it works!
>
> Of course it works!
>
>> get rid of pw_id_map, run authck, check homedirs and it works. sys
>> owns tcb so you should be ok, if you get uid errors then there is a
>> mismatch, either not in tcb... or passwd.
>
> This is ok, but I am not thinking about, whether it works from the
> technical point of view. My position is to look how human beeings think
> and work. And if human beeings rely on that something works technically,
> they stop to think.
> Just an example I could watch in my time at the support center:
> - admin joins two passwds by a quite tricky script (he was quite
> proud of ...),
> - oradm user gets the wrong userID,
> - causes on of the largest shop-systems in Austria not to
> sell for nearly three days,
> - makes the stock exchange quotation go down.
> - very unlucky Ex-admin
>
> Sorry for my unconvenient opinion, but scripts and automatisms make
> people stop thinking too often.
>
> Florian
>
>
Except......... we do not have dup uid's, (.) across all of our env's we
have always kept them unique, LDAp before anyone thought of it, and we
didn't call it that, just knew it would make things alot easier in the
long run. 4 sure if u dont do it right you will toast !! no doubt! if
you pay attention it works!