Solaris Naming Administration Guide

The DES Credential in Detail

The DES credential consists of:

DES Credential Secure RPC Netname

Note -

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

Table 7-1 Secure RPC Netname Format









Domain containing user's password entry and the DES credential itself 




The domain name returned by executing the domainname command on that workstation 

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:

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

  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: