DES Credential in NIS+

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 in NIS+).

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

Table 12-1 Secure RPC Netname Format

DES Credential Verification Field in NIS+

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 NIS+ Request Phase - Detailed Description

• The encrypted time stamp

• The time window

How the DES Credential in NIS+ 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.

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 an NIS+ 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 in NIS+

Secure RPC Passwords and the Login Password Problem in NIS+

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.

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 With NIS+.)

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 in NIS+

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 nisupdkeys Command for information on using the nisupdkeys command and Stale and Outdated NIS+ Credential Information for information on how to correct this type of problem.)

• Stopping the NIS+ service on your machine by using the svcadm command, removing /var/nis/NIS_SHARED_DIRCACHE, and then restarting the NIS+ service.