The DES Credential in Detail
The DES credential consists of:
The principal's Secure RPC netname (see "DES Credential Secure RPC Netname").
A verification field (see "DES Credential Verification Field").
DES Credential Secure RPC Netname
Secure RPC netname. This portion of the credential is used to identify the NIS+ principal. Every Secure RPC netname contains three components:
Prefix. The prefix is always the word unix.
Identifier. If the principal is a client user, the ID field is the user's UID. If the principal is a client machine, the ID field is the machine's hostname.
Domain name. The domain name is the name of the domain that contains the principal's DES credential (in other words, the principal's home domain).
Note - Remember that an NIS+ principal name always has a trailing dot, and a Secure RPC netname never has a trailing dot.
Table 12-1 Secure RPC Netname Format
Principal | Prefix | Identifie | Domain | Example |
|---|---|---|---|---|
User | unix | UID | Domain containing user's password entry and the DES credential itself | unix.24601@sales.doc.com |
machine | unix | hostname | The domain name returned by executing the domainname command on that machine | unix.machine7@sales.doc.com |
DES Credential Verification Field
The verification field is used to make sure the credential is not forged. It is generated from the credential information stored in the cred table.
The verification field is composed of:
The principal's encrypted DES key, generated from the principal's private key and the NIS+ server's public key as described in "Request Phase--Detailed Description"
The encrypted time stamp
The time window
How the DES Credential Is Generated
To generate its DES credential, the principal depends on the keylogin command, which must have been executed before the principal tries to generate its credential. The keylogin command (often referred to simply as a keylogin) is executed automatically when an NIS+ principal logs in. See Figure 12-2.
Note - Note that if the principal's login password is different from the principal's Secure RPC password, a successful keylogin cannot be performed. See "Secure RPC Password Versus Login Password Problem" for a discussion of this situation.
The purpose of the keylogin is to give the principal access to the principal's private key. keylogin fetches the principal's private key from the cred table, decrypts it with the principal's Secure RPC password (remember that the private key was originally encrypted with the principal's Secure RPC password), and stores it locally with the keyserver for future NIS+ requests.
Figure 12-1 keylogin Generates a Principal's Private Key
To generate its DES credential, the principal still needs the public key of the server to which it will send the request. This information is stored in the principal's directory object. Once the principal has this information, it can form the verification field of the credential.
First, the principal generates a random DES key for encrypting various credential information. The principal uses its own private key (stored in the keyserver) and the server's public key to generate a common key that is used to generate and encrypt the random DES key. It then generates a time stamp that is encrypted with the DES key and combines it with other credential-related information into the verification field:
Figure 12-2 Creating the DES Credential
Secure RPC Password Versus Login Password Problem
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 the principal 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" 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 a 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 recurs. To permanently solve the problem the user needs to re-encrypt 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 needs to run chkey -p as described in "Changing Keys for an NIS+ Principal".
Thus, to permanently solve problems related to a difference in Secure RPC password and login password, the user (or an administrator acting for the user) must perform these 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 -p to permanently change the encrypted private key in the cred table to one based on the user's login password.
When you are ready to finish this login session, run keylogout.
Log off the system with logout.
Cached Public Keys Problems
Occasionally, you might find that even though you have created the proper credentials and assigned the proper access rights, some principal requests still get denied. The most common cause of this problem 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 "The nisupdkeys Command" for information on using the nisupdkeys command and "Stale and Outdated Credential Information" for information on how to correct this type of problem.)
Killing the nis_cachmgr on your machine, removing /var/nis/NIS_SHARED_DIRCACHE, and then restarting nis_cachemgr.
Where Credential-Related Information Is Stored
This section describes where credential-related information is stored throughout the NIS+ 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, do not. lists all the objects, tables, and files that store credential-related information and how to reset it.
Table 12-2 Where Credential-Related Information Is Stored
Item | Stores | To Reset or Change |
|---|---|---|
cred table | NIS+ principal's public key and private 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 /usr/lib/nis/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 -rfor a principal machine. |
NIS+ daemon | Copies of directory objects, which in turn contain copies of their servers' public keys. | Kill the rpc.nisd daemon and the cache manager and remove NIS_SHARED_DIRCACHE from /var/nis. 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 nis_cachemgr -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. On a client machine, first remove the NIS_COLD_START and NIS_SHARED_DIRCACHE 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 machine's NIS_COLD_START file. |
passwd table | A user's password. | Use the passwd -r nisplus 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 machine's superuser password. | Use the passwd -r nisplus command, whether logged in as super user or as yourself, whichever is appropriate. |
passwd map (NIS) | A user's password | Use the passwd -r nisplus command. |