This is original post:
> After I changed the root password on the root master, I emailed out this as a
> reminder to another sysadmin. She tells me that she just used 'passwd' to
> change the root passwd the previous time, but did not do the next two steps.
>
> The FAQ warns that 'If you use any other method for updating your root
> passwd, you can totally mess up your NIS+ domain', but it does not mention
> *how*/*what* you can mess up.
I got three responses, all good, so I've included them below.
Thanks a lot everyone!
Rasana
---------------------------------------------------------------------------
From: Charles Gagnon <charles@Grafnetix.COM>
I think that totally messing up is a big word. The main problem is the
authentication.
To authenticate, NIS+ uses the DES cryptography algorythm who uses the "Public
Key" method for authentication.
The way the keys work is that you use a public key to encrypt information you
send and a private key to decrypt the information. In order to have a full
fonctionning authentication for the root user of a machine, you the the root
passwd on both the client and the NIS+ server. That's why, when you setup a
client and/or a rootmaster server, you need to type in the root passwd of the
machine.
If you change this passwd on the machine but not in the credentials table of
the NIS+ cloud (cred.org_dir), your machine won't be able to reconstruct the
key probably resulting in problems with the NIS+.
Exemples of problems:
- login as root and run admintool, nistbladm or other NIS+ administration
command could become impossible.
Hope I helped.
---------------------------------------------------------------------------
From: Jim Harmon <jharmon@telecnnct.com>
> > This changes the private key for the server, while the public key
> > remains the same. This is necessary because clients use server's
> > public key for authentication.
This is the answer you're looking for.
If you can't validate who the server is, your clients won't validate
network requests. This could potentially prevent all network activity
on your LAN.
---------------------------------------------------------------------------
From: "EG Keizer" <keie@cs.vu.nl>
1 . #passwd
is used to change the password. If you do not do this, the following
two commands server no purpose and do no harm.
2. #chkey -p
is used to re-encrypt the crypted private key in the cred table with the new
password. It will ask for the current server root password.
2. #keylogin -r
is somewhat superfluous if you have done nothing wrong in steps 1 and 2. It
gets the encrypted private key form cred table, decrypts it and stores it in
/etc/.rootkey. But... "chkey" changed only the encryption of the private key,
not the private key. Thus the contents of /etc/.rootkey are identical to what
they were before.
There are two things that can go wrong here:
1. Your private key is still encrypted with your old password. This, in itself,
is not harmful since the private key information for the server is stored
in /etc/.rootkey. /etc/rootkey is only changed by `keylogin -r' if you typed the
correct, in this case old, password for decrypting the private key (It can
check :-)
A side effect is that people logging in as root, will see an
'Unable to decrypt secret key message.....' This might excite them into
giving a chkey command WITHOUT the -p. For that see case 2.
2. Your public and private key have changed. This happens when you forget
to use the `-p' with `chkey'. This leads to a complete disaster. Secure RPC
between the NIS server and ALL clients will fail. This effectively stops
the server from being useful. This situation can not be remedied without
restarting the server under very special circumstances.
---------------------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Rasana Atreya Voice: (415) 476-3623 ~
~ System Administrator Fax: (415) 476-4653 ~
~ Library & Ctr for Knowledge Mgmt, Univ. of California at San Francisco ~
~ 530 Parnassus Ave, Box 0840, San Francisco, CA 94143-0840 ~
~ atreya@library.ucsf.edu ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~