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).

Remember that an NIS+ principal name always has a trailing dot, and a Secure RPC netname never has a trailing dot.

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 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.

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:

1. Log in using the login password.

2. Run the keylogin program to temporarily get a decrypted private key stored in the keyserver and thus gain temporary NIS+ access privileges.

3. Run chkey -p to permanently change the encrypted private key in the cred table to one based on the user's login password.

4. When you are ready to finish this login session, run keylogout.

5. 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.