This section describes common password, credential, encryption, and other security-related problems.
Error messages with operative clauses such as:
"Authentication error"
"Authentication denied"
"Cannot get public key"
"Chkey failed"
"Insufficient permission to"
"Login incorrect"
"Keyserv fails to encrypt"
"No public key"
"Permission denied"
"Password [problems]"
User or root unable to perform any namespace operations or tasks. (See also Ownership and Permission Problems.)
The most common cause of a "login incorrect" message is the user mistyping the password. Have the user try it again. Make sure the user knows the correct password and understands that passwords are case-sensitive and that the letter "o" is not interchangeable with the numeral "0," nor is the letter "l" the same as the numeral "1."
Other possible causes of the "login incorrect" message are:
See Administering Passwords for more information.
A common cause of a "Permission denied, password expired," type message is that the user's password has passed its age limit or the user's password privileges have expired. See Administering Passwords for more information on passwords.
Occasionally, you may find that even though you have created the proper credentials and assigned the proper access rights, some client requests still get denied. This may be due to out-of-date information residing somewhere in the namespace.
Credential-related information, such as public keys, is stored in many locations throughout the namespace. NIS+ updates this information periodically, depending on the time-to-live values of the objects that store it, but sometimes, between updates, it gets out of sync. As a result, you may find that operations that should work, don't work. The following table lists all the objects, tables, and files that store credential-related information and how to reset it.
| Item | Stores | To Reset or Change |
|---|---|---|
| cred table | NIS+ principal's secret key and public key. These are the master copies of these keys. | Use nisaddcred to create new credentials; it updates existing credentials. An alternative is chkey. |
| Directory object | A copy of the public key of each server that supports it. | Run the nisupdkeys command on the directory object. |
| Keyserver | The secret key of the NIS+ principal that is currently logged in. | Run keylogin for a principal user or keylogin -r for a principal workstation. |
| NIS+ daemon | Copies of directory objects, which in turn contain copies of their servers' public keys. | Kill the daemon and the cache manager. Then restart both. |
| Directory cache | A copy of directory objects, which in turn contain copies of their servers' public keys. | Kill the NIS+ cache manager and restart it with the stopsrc -s nis_cachemgr -a "-i" command. The -i option resets the directory cache from the cold-start file and restarts the cache manager. |
| Cold-start file | A copy of a directory object, which in turn contains copies of its servers' public keys. | On the root master, kill the NIS+ daemon and restart it. The daemon reloads new information into the existing NIS_COLD_START file.
For a client, first remove the cold-start and shared directory files from /var/nis, and kill the cache manager. Then re-initialize the principal with nisinit -c. The principal's trusted server reloads new information into the principal's existing cold-start file. |
| passwd table | A user's password or a workstation's superuser password. | Use the passwd command. It changes the password in the NIS+ passwd table and updates it in the cred table. |
| passwd file | A user's password or a workstation's superuser password. | Use the passwd command, whether logged in as superuser or as yourself, whichever is appropriate. |
The most commonly encountered out-of-date information is the existence of stale objects with old versions of a server's public key. You can usually correct this problem by running nisupdkeys on the domain you are trying to access. (See Administering NIS+ Credentials, for information on using the nisupdkeys command.)
Because some keys are stored in files or caches, nisupdkeys cannot always correct the problem. At times you might need to update the keys manually. To do that, you must understand how a server's public key, once created, is propagated through namespace objects. The process usually has five stages of propagation:
An NIS+ server is first an NIS+ client. So, its public key is generated in the same way as any other NIS+ client's public key: with the nisaddcred command. The public key is then stored in the cred table of the server's home domain, not of the domain the server will eventually support.
Once you have set up an NIS+ domain and an NIS+ server, you can associate the server with a domain. This association is performed by the nismkdir command. When the nismkdir command associates the server with the directory, it also copies the server's public key from the cred table to the domain's directory object. For example, assume the server is a client of the wiz.com. root domain, and is made the master server of the sales.wiz.com. domain.
For more information, see the diagram.Its public key is copied from the cred.org_dir.wiz.com. domain and placed in the sales.wiz.com. directory object. This can be verified with the niscat -o Sales.wiz.com. command.
All NIS+ clients are initialized with the nisinit utility or with the nisclient script.
Among other things, nisinit (or nisclient) creates a cold-start file /var/nis/NIS_COLDSTART. The cold-start file is used to initialize the client's directory cache /var/nis/NIS_SHARED_DIRCACHE. The cold-start file contains a copy of the directory object of the client's domain. Since the directory object already contains a copy of the server's public key, the key is now propagated into the cold-start file of the client.
In addition when a client makes a request to a server outside its home domain, a copy of the remote domains directory object is stored in the client's NIS_SHARED_DIRCACHE file. You can examine the contents of the client's cache by using the nisshowcache command.
This is the extent of the propagation until a replica is added to the domain or the server's key changes.
When a replica server is added to a domain, the nisping command is used to download the NIS+ tables, including the cred table, to the new replica. Therefore, the original server's public key is now also stored in the replica server's cred table.
If you decide to change DES credentials for the server (that is, for the root identity on the server), its public key will change. As a result, the public key stored for that server in the cred table will be different from those stored in:
Most of these locations will be updated automatically within a time ranging from a few minutes to 12 hours. To update the server's keys in these locations immediately, use the commands:
| Location | Command |
|---|---|
| cred table of replica servers (instead of using nisping, you can wait a few minutes until the table is updated automatically) | nisping |
| Directory object of domain supported by server | nisupdkeys |
| NIS_COLDSTART file of clients | nisinit -c |
| NIS_SHARED_DIRCACHE file of clients | nis_cachemgr |
Note: You must first kill the existing nis_cachemgr before restarting nis_cachemgr.
When a principal (user or machine) has a corrupt credential, that principal is unable to perform any namespace operations or tasks, not even nisls. This is because a corrupt credential provides no permissions at all, not even the permissions granted to the nobody class.
User or root cannot perform any namespace tasks or operations. All namespace operations fail with a "permission denied" type of error message. The user or root cannot even perform a nisls operation.
Corrupted keys or a corrupt, out-of-date, or otherwise incorrect /etc/.rootkey file.
Use iptrace to identify the bad credential.
Or, if the principal is listed, log in as the principal and try to run an NIS+ command on an object for which you are sure that the principal has proper authorization. For example, in most cases an object grants read authorization to the nobody class. Thus, the nisls object command should work for any principal listed in the cred table. If the command fails with a "permission denied" error, then the principal's credential is likely corrupted.
The keyserv is unable to encrypt a session. There are several possible causes for this type of problem:
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.
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.
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.
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.
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.
The /etc/irs.conf file specifies which password is used for which purpose. If the /etc/irs.conf file is directing system queries to the wrong location, you will get password and permission errors.
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.
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.) (In this context, net work password is sometimes used as a synonym for Secure RPC password. When prompted for your network password, enter your Secure RPC password.)
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 a 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:
Various "insufficient permission to" and "permission denied" error messages.
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.
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.
Run keylogin -r as root on the problem machine and then set up the machine as a client again.
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.
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. (Note that you should not have UserID 0 in the password table.)
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.
Note: 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.