NIS+ - Changing root passwords

NIS+ - Changing root passwords

Post by Rob Masca » Sat, 18 Mar 1995 10:32:33



Demand has caused me to post this summary of how to change root passwords on
clients, root master servers, and non root servers (replica's). Most of the
problems were caused by Sun themselves not telling their customers how
to do properly (I can quote patch-ids!).

From rob Thu Mar 16 15:59:48 1995

Subject: Re: root passwords

I gather that the workstations are NIS+ clients. If so, this is how I would
do it.

Change the passwords on the clients first. Remember that the clients should
have des credentials only. On the master server create new credentials,
this will create a new public and private key for the client.

It will ask you to enter in the clients root password. Make sure that this
is the NEW password.  

Log onto the client and rm -rf /var/nis.  Change the root password now.
Kill the cache manager and initialise the client, I usually do this by
broadcast as my clients are on the same subnet, if not do it by hostname.
nisinit -c -B
That should be it for the clients.

Because a nis replica is essentially a client of the master, use the
above method to change it's password. Remember after all of this to
propagate the server's tables by doing a nisping -C.

As for the master, take a backup copy of /var/nis/* and /etc/.rootkey
first. I personally would do this after hours or in a CC slot.

Change the root password, using passwd.
run chkey -p . This will generate a new private key, and update /etc/.rootkey
The root account keeps its private key in this file in case "keyserv" is
down!
Thats it. The change will be propagated to the replica. You should not
have to change the replica at all only checkpoint the master.

Do not run "nisaddcred des" or nisupdkeys under any circumstances (unless
you have trashed nis). You will change the public key and even lock the
master out from itself! If you do accidently change the public key, do a
"nisaddcred des" on the root master server and propagate this using a
nisupdkeys on "org_dir.domain" "groups_dir.domain" and "domain". If you have
large tables this may take 5 to 10 minutes and your users will not be able
to see the name space (log in) until it is finished.

Good luck, hope this helps.

--
  \        =                                                        ,-_|\

  /\/(_)\|/|\     Systems Administrator  phone:  +61 9 2221733     *_,-._/
                  Police                 Perth, Western Australia       v

 
 
 

NIS+ - Changing root passwords

Post by Charles Stephen » Sun, 19 Mar 1995 07:06:14


There is a much easier way if you just want to change the login
passwords for root on any NIS+ server or client:

/usr/bin/passwd

Since the DES creds for any NIS+ root prinicpal is unencrypted in
/etc/.rootkey, there is no need to change the key, just the password.

We have been changing pw's on all of our clients and servers with out
problems just with /bin/passwd.

cfs

: Demand has caused me to post this summary of how to change root passwords on
: clients, root master servers, and non root servers (replica's). Most of the
: problems were caused by Sun themselves not telling their customers how
: to do properly (I can quote patch-ids!).

: From rob Thu Mar 16 15:59:48 1995

: Subject: Re: root passwords

: I gather that the workstations are NIS+ clients. If so, this is how I would
: do it.

: Change the passwords on the clients first. Remember that the clients should
: have des credentials only. On the master server create new credentials,
: this will create a new public and private key for the client.

: It will ask you to enter in the clients root password. Make sure that this
: is the NEW password.  

: Log onto the client and rm -rf /var/nis.  Change the root password now.
: Kill the cache manager and initialise the client, I usually do this by
: broadcast as my clients are on the same subnet, if not do it by hostname.
: nisinit -c -B
: That should be it for the clients.

: Because a nis replica is essentially a client of the master, use the
: above method to change it's password. Remember after all of this to
: propagate the server's tables by doing a nisping -C.

: As for the master, take a backup copy of /var/nis/* and /etc/.rootkey
: first. I personally would do this after hours or in a CC slot.

: Change the root password, using passwd.
: run chkey -p . This will generate a new private key, and update /etc/.rootkey
: The root account keeps its private key in this file in case "keyserv" is
: down!
: Thats it. The change will be propagated to the replica. You should not
: have to change the replica at all only checkpoint the master.

: Do not run "nisaddcred des" or nisupdkeys under any circumstances (unless
: you have trashed nis). You will change the public key and even lock the
: master out from itself! If you do accidently change the public key, do a
: "nisaddcred des" on the root master server and propagate this using a
: nisupdkeys on "org_dir.domain" "groups_dir.domain" and "domain". If you have
: large tables this may take 5 to 10 minutes and your users will not be able
: to see the name space (log in) until it is finished.

: Good luck, hope this helps.

: --
:   \        =                                                        ,-_|\

:   /\/(_)\|/|\     Systems Administrator  phone:  +61 9 2221733     *_,-._/
:                   Police                 Perth, Western Australia       v

--
/-------------------\  Charles "*-Buddha" Stephens
| HELLO, my name is |  UNIX Systems Administrator
|-------------------|  Network Systems/Open Systems Group,

| Charles Stephens  |  Emory University, Atlanta, Georgia, USA
|                   |  "You shall soon achieve perfection."  -Fortune Cookie
\-------------------/     http://www.veryComputer.com/~cfs

 
 
 

NIS+ - Changing root passwords

Post by William Mall » Sun, 19 Mar 1995 14:54:48


So much mis-information in one posting, I'm amazed!

1) chkey -p     Does not generate a new private key (that is what -p means,
                preserve the public/private key pair).  Instead it REENCRYPTS
                the old privatekey with the new password.

2) /etc/.rootkey is NOT for when the keyserver is down.  It is the private key
                 in the "clear", i.e. unecrypted.  This is so the keyserver
                 knows what it is after a reboot.  It intended to solve the
                 problem of authenticating "root" if the machine gets rebooted.
                 The alternative is to have someone go around and login as
                 "root" every time a machine reboots.

3) NIS+ clients Use "passwd" to change the root password, and then "chkey -p"
                This "nisaddcred" and "rm -rf /var/nis" stuff is unnecessary.

4) If you do change a servers publickey (bad news) doing both "nisupdkeys" and
   "nisping" on all the directorys served "domainname", "groups_dir.dominname."
   and "org_dir.domainname." and waiting for the TTL expire is your best hope.
   The nis_cachemgr on each client should update the directory objects that
   contain the publickey in the TTL time (default 12 hours).
   (personally I would recover from backups, it's a lot quicker (see next))

5) ALWAYS ALWAYS ALWAYS backup /etc/.rootkey and all of /var/nis.  Recovery
   is going to be a LOT faster.  We backup over NFS.  You can recover a
   server in under 5 minutes that way.  You can spend more time rebooting.

=wpm    William P. Malloy               SunSoft         Networking


>Demand has caused me to post this summary of how to change root passwords on
>clients, root master servers, and non root servers (replica's). Most of the
>problems were caused by Sun themselves not telling their customers how
>to do properly (I can quote patch-ids!).

>From rob Thu Mar 16 15:59:48 1995

>Subject: Re: root passwords

>I gather that the workstations are NIS+ clients. If so, this is how I would
>do it.

>Change the passwords on the clients first. Remember that the clients should
>have des credentials only. On the master server create new credentials,
>this will create a new public and private key for the client.

>It will ask you to enter in the clients root password. Make sure that this
>is the NEW password.  

>Log onto the client and rm -rf /var/nis.  Change the root password now.
>Kill the cache manager and initialise the client, I usually do this by
>broadcast as my clients are on the same subnet, if not do it by hostname.
>nisinit -c -B
>That should be it for the clients.

>Because a nis replica is essentially a client of the master, use the
>above method to change it's password. Remember after all of this to
>propagate the server's tables by doing a nisping -C.

>As for the master, take a backup copy of /var/nis/* and /etc/.rootkey
>first. I personally would do this after hours or in a CC slot.

>Change the root password, using passwd.
>run chkey -p . This will generate a new private key, and update /etc/.rootkey
>The root account keeps its private key in this file in case "keyserv" is
>down!
>Thats it. The change will be propagated to the replica. You should not
>have to change the replica at all only checkpoint the master.

>Do not run "nisaddcred des" or nisupdkeys under any circumstances (unless
>you have trashed nis). You will change the public key and even lock the
>master out from itself! If you do accidently change the public key, do a
>"nisaddcred des" on the root master server and propagate this using a
>nisupdkeys on "org_dir.domain" "groups_dir.domain" and "domain". If you have
>large tables this may take 5 to 10 minutes and your users will not be able
>to see the name space (log in) until it is finished.

>Good luck, hope this helps.

 
 
 

NIS+ - Changing root passwords

Post by Rob Masca » Tue, 28 Mar 1995 10:55:01



>So much mis-information in one posting, I'm amazed!

>1) chkey -p Does not generate a new private key (that is what -p means,
>            preserve the public/private key pair).  Instead it REENCRYPTS
>            the old privatekey with the new password.

In fact, it will generate new private "data". The private key will not change as
suggested.

Quote:>2) /etc/.rootkey is NOT for when the keyserver is down.  It is the private key
>             in the "clear", i.e. unecrypted.  This is so the keyserver
>             knows what it is after a reboot.  It intended to solve the
>             problem of authenticating "root" if the machine gets rebooted.
>             The alternative is to have someone go around and login as
>             "root" every time a machine reboots.

Keyserver is supposed to replace the old /etc/publickey file. /etc/.rootkey
is there to authenticate root when keyserver is down. ie. when rebooting.

groups_dir.dominname."

Quote:>   and "org_dir.domainname." and waiting for the TTL expire is your best hope.
>   The nis_cachemgr on each client should update the directory objects that
>   contain the publickey in the TTL time (default 12 hours).
>   (personally I would recover from backups, it's a lot quicker (see next))

>5) ALWAYS ALWAYS ALWAYS backup /etc/.rootkey and all of /var/nis.  Recovery
>   is going to be a LOT faster.  We backup over NFS.  You can recover a
>   server in under 5 minutes that way.  You can spend more time rebooting.

If you had read the entire post, that is exactly what was said. It is
imperitive to backup /var/nis and .rootkey

In fact, if SUN had got their act together, they would have trained
their support staff in how to solve NIS+ problems, not letting people
like myself to wade around in the dark hopelessly trying to solve complex
NIS+ problems. We have in Australia, *ONE* NIS+ Sun support person.

Anyone wanting to install NIS+, don't. You will have to put up with mis
information, SUN people who don't know what they are talking about, bugs,
and one textbook that is about as secretive as a windows API book!

For the people that are interested in this shambles have a read of the
first patch I was sent to change passwords. It is completely wrong.

Now you talk to me about mis-information.


Subject: root passwd change on NIS+

Collection: Symptoms and Resolutions
Document: 6285

SRDB ID: 6285

SYNOPSIS: change of root passwd on NIS+ server breaks authentication

DETAIL DESCRIPTION:

Proper procedures need to be taken when changing root passwd on
NIS+ server (Master/Replica)

This impacts NIS+ operation under security level 2 (default)

NIS+ requests may fail due to autherisation errors.

SOLUTION SUMMARY:

If the change of password has already been done, the following should
recover the previous NIS+ state.

        kill and restart rpc.nisd at security level 0

ps -ef | grep rpc.nisd
kill <pid>
/usr/sbin/rpc.nisd -r -S 0

        Use keylogout to remove roots key

keylogout -f

        Now add root's key and push it into the directories:

nisaddcred des
nisupdkeys `nisdefaults -d`
nisupdkeys org_dir.`nisdefaults -d`
nisupdkeys groups_dir.`nisdefaults -d`

Now make sure the changes have been propagated.

/usr/lib/nis/nisping `nisdefaults -d`
/usr/lib/nis/nisping org_dir.`nisdefaults -d`
/usr/lib/nis/nisping groups_dir.`nisdefaults -d`

        and any other directories that you may have created.

        kill & restart nis at security level 2

ps -ef | grep rpc.nisd
kill <pid>
/usr/sbin/rpc.nisd -r -S 2

BUG REPORT ID: n/a
PATCH ID: n/a
PRODUCT AREA: n/a
PRODUCT: NIS+
SUNOS RELEASE: 2.0, All
UNBUNDLED RELEASE: n/a
HARDWARE: All

 
 
 

1. NIS+...Changing root passwords

I've been fighting this problem for years now, and have yet
to get a working solution.

My question is this:  How do I change the root password on
an NIS+ server and NOT screw up the entire domain.  There
are various articles about this on SunSolve, some of which
conflict with each other, and none of which have ever worked
for me.

Here's the latest I got from the Solaris 7 Answerbook:

1. Change the root password.

2. Update the keys on the root server by doing the following:

        nisaddcred des
        pkill rpc.nisd
        rpc.nisd -S0
        keylogout -f
        nisupdkeys <dirs> (I used:
                        org_dir.`domainname`.
                        groups_dir.`domainname`.
                        `domainname`. all on one line.)
        pkill rpc.nisd
        rpc.nisd
        keylogin

3. Update the client key info:

        nischttl 60 `domainname`.

This breaks NIS+.  The master server, the replicas, and all the
clients respond with "Cannot authenticate NIS+ server" or some
such error message.

Has anyone ever gotten this to work successfully?  Please help!

TIA!

-geo

2. Vi stdin and fifo's

3. NIS+ user management [Was: Re: root changing a user's password (NIS)]

4. Problem with WU-ftpd

5. changing NIS+ root master root password

6. RPM problems

7. Changing local root password on box running NIS

8. LSM - What and How?

9. changing root password on a NIS+ server

10. User password change by root using NIS

11. Changing root password (NIS+)

12. NIS+ root password change

13. how to change root password on NIS+ master server