Keyserv Failure
The keyserv is unable to encrypt a session. There are several possible causes for this type of problem:
Possible Causes and Solutions:
The client has not keylogged in. Make sure that the client is keylogged in. To determine if a client is properly keylogged in, have the client run nisdefaults -v (or run it yourself as the client). If (not authenticated) is returned on the Principal Name line, the client is not properly keylogged in.
The client (host) does not have appropriate LOCAL or DES credentials. Run niscat on the client's cred table to verify that the client has appropriate credentials. If necessary, add credentials as explained in "Creating Credential Information for NIS+ Principals".
The keyserv daemon is not running. Use the ps command to see if keyserv is running. If it is not running, restart it and then do a keylogin.
While keyserv is running, other long running processes that make secure RPC or NIS+ calls are not. For example, automountd, rpc.nisd, and sendmail. Verify that these processes are running correctly. If they are not, restart them.
Machine Previously Was an NIS+ Client
If this machine has been initialized before as an NIS+ client of the same domain, try keylogin -r and enter the root login password at the Secure RPC password prompt.
No Entry in the cred Table
To make sure that an NIS+ password for the principal (user or host) exists in the cred table, run the following command in the principal's home domain
nisgrep -A cname=principal cred.org_dir.domainname |
If you are running nisgrep from another domain, the domainname must be fully qualified.
Changed Domain Name
Do not change a domain name.
If you change the name of an existing domain you will create authentication problems because the fully qualified original domain name is embedded in objects throughout your network.
If you have already changed a domain name and are experiencing authentication problems, or error messages containing terms like "malformed" or "illegal" in relation to a domain name, change the domain name back to its original name. The recommended procedure for renaming your domains is to create a new domain with the new name, set up your machines as servers and clients of the new domain, make sure they are performing correctly, and then remove the old domain.
When Changing a Machine to a Different Domain
If this machine is an NIS+ client and you are trying to change it to a client of a different domain, remove the /etc/.rootkey file, and then rerun the nisclient script using the network password supplied by your network administrator or taken from the nispopulate script.
NIS+ and Login Passwords in /etc/passwd File
Your NIS+ password is stored in the NIS+ passwd table. Your user login password may be stored in NIS+ passwd table or in your /etc/passwd file. (Your user password and NIS+ password can be the same or different.) To change a password in an /etc/passwd file, you must run the passwd command with the nsswitch.conf file set to files or with the -r files flag.
The nsswitch.conf file specifies which password is used for which purpose. If the nsswitch.conf file is directing system queries to the wrong location, you will get password and permission errors.
Secure RPC Password and Login Passwords Are Different
When a principal's login password is different from his or her Secure RPC password, keylogin cannot decrypt it at login time because keylogin defaults to using the principal's login password, and the private key was encrypted using the principal's Secure RPC password.
When this occurs the principal can log in to the system, but for NIS+ purposes is placed in the authorization class of nobody because the keyserver does not have a decrypted private key for that user. Since most NIS+ environments are set up to deny the nobody class create, destroy, and modify rights to most NIS+ objects this results in "permission denied" types errors when the user tries to access NIS+ objects.
Note - In this context network password is sometimes used as a synonym for Secure RPC password. When prompted for your "network password," enter your Secure RPC password.
To be placed in one of the other authorization classes, a user in this situation must explicitly run the keylogin program and give the principal's Secure RPC password when keylogin prompts for password. (See "Keylogin".)
But an explicit keylogin provides only a temporary solution that is good only for the current login session. The keyserver now has a decrypted private key for the user, but the private key in the user's cred table is still encrypted using the user's Secure RPC password, which is different than the user's login password. The next time the user logs in, the same problem reoccurs. To permanently solve the problem the user needs to change the private key in the cred table to one based on the user's login ID rather than the user's Secure RPC password. To do this, the user need to run the chkey program as described in "Changing Keys for an NIS+ Principal".
Thus, to permanently solve a Secure RPC password different than login password problems, the user (or an administrator acting for the user) must perform the following steps:
Log in using the login password.
Run the keylogin program to temporarily get a decrypted private key stored in the keyserver and thus gain temporary NIS+ access privileges.
Run chkey -pto permanently change the encrypted private key in the cred table to one based on the user's login password.
Preexisting /etc/.rootkey File
Symptoms:
Various insufficient permission to and permission denied error messages.
Possible Cause:
An /etc/.rootkey file already existed when you set up or initialized a server or client. This could occur if NIS+ had been previously installed on the machine and the .rootkey file was not erased when NIS+ was removed or the machine returned to using NIS or /etc files.
Diagnosis:
Run ls -l on the /etc directory and nisls -l org_dir and compare the date of the /etc/.rootkey to the date of the cred table. If the /etc/.rootkey date is clearly earlier than that of the cred table, it may be a preexisting file.
Solution:
Run keylogin -r as root on the problem machine and then set up the machine as a client again.
Root Password Change Causes Problem
Symptoms:
You change the root password on a machine, and the change either fails to take effect or you are unable to log in as superuser.
Possible Cause:
Note - For security reasons, you should not have User ID 0 listed in the passwd table.
You changed the root password, but root's key was not properly updated. Either because you forgot to run chkey -p for root or some problem came up.
Solution
Log in as a user with administration privileges (that is, a user who is a member of a group with administration privileges) and use passwd to restore the old password. Make sure that old password works. Now use passwd to change root's password to the new one, and then run chkey -p.
Caution - Once your NIS+ namespace is set up and running, you can change
the root password on the root master machine. But do not change the root master
keys, as these are embedded in all directory objects on all clients, replicas,
and servers of subdomains. To avoid changing the root master keys, always
use the -p option when running chkey as
root.
NIS+ Performance and System Hang Problems
This section describes common slow performance and system hang problems.
Performance Problem Symptoms
Error messages with operative clauses such as:
Other common symptoms:
You issue a command and nothing seems to happen for far too long.
Your system, or shell, no longer responds to keyboard or mouse commands.
NIS+ operations seem to run slower than they should or slower than they did before.