HOW to CHANGE THE ROOT USER'S PASSWORD ON A NIS+ MACHINE:
------------------------------------------------------------------------------
Certain points must be kept in mind during the creating/updation on root user
entries:
1) It is not recommended to have a root user in the nis+ passwd table, same
applies to any default unix users ( bin,daemon,uucp,admin, etc..)
2) The preferred method is to have the passwd entry of the root in the local
("files") repository.
3) root of every machine in the nis+ domain, is represented in the nis+ by the
machine's name, so will have credentials specified by the name of the
machine,
ie "unix.manicne@domain".
3) The passwd command should be used to change the local passwd for the root.
As the passwd will be found locally (if the recommendation is followed),
the command not longer tries to change the nis+ credentials for this
principle , ie "root" .a.k.a unix.machine@domainanme
4) If you have root in the nis+ table, the password for the local root user is
changed only after it ( the "passwd" comand) can change the passwd for the
root entry in the nis+ database, and also the associated credentials for
unix.0@doamin, which will be clumsy as every root on the network has the
uid 0, and is the very reason for not putting the root entry in the nis+
database.
5) Once "passwd" has been used to change the root user's passwd in the
/etc/passwd file, it is time to synchronize the credentials (the password
used to encrypt the secret key) for this hostmachine in the nis+ cred table.
6) The cred update is accomplished by chkey -p command which will ask for the
previous secure rpc/nis+ passwd. (It is always better to do a keylogin
before this command as nis+ password the user knows can be confirmed as a
good one). The -p is important as it will preserve the rpc keys and only
reencrypt the secret key using the new passwd provided, instead of
generating
new keys. This is essential on the master and the replica machines as the
clients needs to know the servers public key along with its own private key
to complete a secure rpc transaction.
7) The steps "keylogin", "passwd", and "chkey -p" can be performed on any
nis+ client, which include the root master and replica machines which are
also clients of nis+.
8) Normally after the process is complete it is better to do a nisping on all
the three direcories: "domain.", "org_dir.domain.", "groups_dir.domain.a"
=============================================================================
Procedure to change the password for the root users on nis+ machines
(masters/replicas/clients)
1) Login on to the nis+ machine as user "root".
---> If you cannot login which the root password, please use OS CD-ROM to
change the password before proceeding.
---> If you see "cannot decrypt secret key for unix.hostname@domainame.
"message, follow the "create new credentials" section of this infodoc.
---> If no problems go to step 2.
2) Execute an explicit "keylogin", even though the login does an "keylogin"
implictly. This is required to check if the nis+ password known by the root
user on this machine is valid.
# keylogin
<will ask for password. Provide the nis+ password of the root user of this
machine (which is the password used to create credentials for this machine
in nis+, would normally be the same as the root login password, or would be
"nisplus" if the NIS+ tables were just populated).
-> If the keylogin fails with "Password incorrect for unix.machine@domain.",
try "keylogin" with other possible passwords, and if it does not work,
follow the "create new credentials" section of this infodoc.
-> If the keylogin was successful go to the step 3
3) Change the root user's login password using the 'passwd' command.
#passwd
-> Any difficulty during this command will need normal troubleshooting
without any effect of or on NIS+.
-> After the login password has been changed successfully for root user go
to step 4
4) Now the nis+ password (or the network password or the secure RPC password
as it is also called) needs to be changed. This can be performed by the
'chkey -p' command. The -p option is necessary as it will restrict the
chkey command to use the existing public and the private key for the
principal (the unix.machine@domain in this case). It is very important not
to change the public rpc key, specially incase of servers, as the clients
need the server's public key to transact with server and with the public key
changed the clients will not be able to talk to the server (mostly "Unable
to authenticate NIS+" will result), unless reinitialised.
#chkey -p
<This command will ask you for the old secure RPC password. Enter the same
password you used for the succussful completion of 'keylogin' command.>
<This command will then ask for the login password for the root user.
Provide
the root user's new password>
--> If this command does not complete successfully then previous steps were
not completed carefully.
--> If you have completed this step succesfully, the rootmaster of this
domain has a updated secure RPC password for this machine.
-------------------------------------------------------------------------------
Create new credentials:
=======================
Creation or updation of credentials influnces nis+ in different ways, according
as the principle for which the credentials are being created/updated. The
public keys of the replicas and master for the NIS+ domain are required by the
clients of the domain (the replicas and the Master are also clients of the
domain) for proper authentication during the nis+ requests. All the clients
store the public keys of the servers for the domain in the
/var/nis/NIS_COLD_START file. This file needs to be updated everytime any of
the servers' credentials are updated.
CLIENTs:
--------
1) On a replica server or on the master for the domain run the following
command:
NOTE: Replace CLIENT with the name of the client machine and DOMAIN with the
name of the nis+ domain.
NOTE: This command will create new credentials if they do not exist and
replace then if they exist.
#nisaddcred -p unix.CLIENT@DOMAIN -P CLIENT.DOMAIN. des
<This command will ask for the secure RPC passsword you want to change to.
Provide the new pasword you want to the root password to change to.>
--> This command will normally complete successfully unless the principal
who is trying to create the credentials as does not have permissions
to do so. The master for the domain now has the new secure RPC password
for this client
2) An nis+ object udate on the replicas is recommaneded. The following
commands
can be performed on any replica or master for the domain.
#nisping org_dir.DOMAIN.
#nisping groups_dir.DOMAIN.
#nisping DOMAIN.
3) 0n the client login as the root user and perform a "keylogin -r" to update
the /etc/.rootkey file (essential).
#keylogin -r
4) Password for the root user on the client needs to be change to the new
password using the password command.
#passwd
--> Any difficulty during this command will need normal troubleshooting
without any effect of or on NIS+.
REPLICAS:
---------
At this point something has gone wrong in the credential repositories on the
master or replica servers. The cleanest way to get back the credentilas and the
database, so that further difficulties are not encountered during the
administration of nis+ on this server, is to remove the nis+ from this
server create credentilas for this machine on the root master (similar to
step 1 in the clients case) using 'nisaddcred' command. Then reinitlaise this
machine as a client and then as a replica again.
If reinitialising replica is not an option, then the following steps can be
followed to restore the replica's credentilas.
NOTE: The following method is strictly conditional and full back up is
recommended. Sun does not take reponsibilty for the outcome.
1) On the master (only) for the domain run the following command:
NOTE: Replace REPLICA with the name of the replica machine and DOMAIN with
the name of the nis+ domain.
NOTE: This command will create new credentials if they do not exist and
replace then if they exist.
#nisaddcred -p unix.REPLICA@DOMAIN -P REPLICA.DOMAIN. des
<This command will ask for the secure RPC password you want to change to.
Provide the new pasword you want to the root password to change to.>
--> This command will normally complete successfully as only the root user
on the nis+ domain master should be running this command. If this
command does not complete successfully, Plese check the authentication
capability of root user or YOU WILL HAVE TO CREATE NEW CREDENTILAS FOR
THE MASTER OF THE DOMAIN. The master for the domain now has the new
secure RPC password for this client
2) An nis+ object udate on the replicas is recommaneded. The following
commands
should be performed on master for the domain.
#nisping org_dir.DOMAIN.
#nisping groups_dir.DOMAIN.
#nisping DOMAIN.
3) Login on the replica as root and perform "keylogin -r" to update the secret
key in the /etc/.rootkey file.
# keylogin -r
<This command will ask for a password. Provide the password used while
creating credentilas on the root master>
4) Password for the root user on the replica needs to be change to the new
password using the passwd command.
#passwd
--> Any difficulty during this command should be will need normal
troubleshooting without any effect of or on NIS+.
5) Kill the nis_cachemgr and remove the /var/nis/*DIRCACHE files and restart
the nis_cachemgr.
5) At this point the master and this replica know about chnage in the
credentials for this replica. None of the clients know about the change.
The clients need to wait for about 12 hours before the
/var/nis/NIS_COLD_START file is automatically updated. Till then,
"Unable to authenticate NIS+ server my be seen on the clients". If many
clients are dependent on this replica and need to update thier cold
start file immedeately proceed to the "Updating cold start file" section
of this Infodoc.
ROOT SERVER:
------------
The most damaging condition in a NIS+ environment is the root on the master
server unable to authenicate to the nis+.
Backups and nisaddent dumps should be performed periodically as there is not
surefire method of getting out of this situation.
Reinitialising is the quickest and the cleanest way of getting back the root
master with clean database. If the root users on the replica services are able
to autheticate to NIS+ then nisaddent dump of the database should be performed
to backup the table in their natuaral text format. In 50% of the cases
reinitialisation is the only possible alternative.
The following method can be applied to restore the nis+ credentials for the
master, but Sun claims no replonsibility for the outcomes.
On the NIS+ master server : perform the following steps
1) Login as root user
2) Run 'keylogin' to confirm the inablility to authenticate to nis+.
3) Kill the nis_cachemgr and rpc.nisd.
4) restart rpc.nisd with "-S 0" option
#rpc.nisd -S0
5) Create new credentilas for the master by running 'nisaddred' command
#nisaddcred
<It will ask for new secure password. Provide a new password>
6) Update the keys in the directory objects using the nisupdkeys command.
#nisupdkeys DOMAIN. org_dir.DOMAIN. groups_dir.DOMAIN.
<Replace "DOMAIN" with the nis+ domain name>
--> if the command does not return successfully try couple of times.
7) Perform check point on all the three directories on the master
#nisping -C org_dir.DOMAIN.
#nisping -C groups_dir.DOMAIN.
#nisping -C DOMAIN.
8) keylogout with -f option.
#keylogout -f
9) Kill the running rpc.nisd and restart with original options (-Y -B if any.)
10) Perform a keylogin -r to update the secret key in the /etc/.rootkey.
If all the above 10 steps are performed successfully the root credentilas were
successfully changed and the root user's login password can be changed using
the passwd command if needed.
At this point the root master and the client on the root master know about the
updated credentials (as the cold start file onthe master is updated immedately
on any change to the directory objects), the clients of the domain need to
update their cold start files with the correct master credentilas.
11) Perform the steps spcified in the "Updating cold start file" section of
this Infodoc, for the clients to authenticate the nis+ master.
==============================================================================
UPDATING COLD START FILE:
-------------------------
The cold start file is essential for the client server authentication. It is
the original repository of server and server keys for the client. The cache
is created based on the cold start file. The cache is use for run time queries
and need to be refreshed when ever there are major changes take palace in the
domain. The cold start file is only read once while the cache is being created
by the nis_cachemgr.
Perform following steps to update the coldstart file and the nis+ cache.
----> On all clients and replicas
1) kill the nis_Cachemgr
2) remove the /var/nis/*DIRCACHE files
3) run the 'nisinit' command to create a new cold start file
#nisinit -c -H <rootmaster>
4) start the nis_cachemgr.