The cred Table in Detail

Credential information for principals is stored in a cred table. The cred table is one of the 16 standard NIS+ tables. Each domain has one cred table, which stores the credential information of client machines that belong to that domain and client users who are allowed to log into them. (In other words, the principals of that domain.) The cred tables are located in their domains' org_dir subdirectory.

Caution - Never link a cred table. Each org_dir directory must have its own cred table. Never use a link to some other org_dir cred table.

For users, the cred table stores LOCAL credential information for all users who are allowed to log into any of the machines in the domain. The cred table also stores DES credential information for those users that have the domain as their home domain.

You can view the contents of a cred table with the niscat command, described in Chapter 19, Administering NIS+ Tables.

The cred table as shown in Table 12-3 has five columns:

Table 12-3 cred Table Credential Information

The Authentication Type column, determines the types of values found in the other four columns.

• LOCAL. If the authentication type is LOCAL, the other columns contain a principal user's name, UID, and GID; the last column is empty.

• DES. If the authentication type is DES, the other columns contain a principal's name, Secure RPC netname, public key, and encrypted private key. These keys are used in conjunction with other information to encrypt and decrypt a DES credential.

Creating Credential Information

There are several methods of creating and administering credential information:

• Use Solstice AdminSuite tools if you have them available. They provide easier methods of credential administration and are recommended for administering individual credentials.

• Use the nisclient script. This is another easy method of creating or altering credentials for a single principal. Because of its convenience, this is a recommended method of administering individual credentials. gives step by step instructions on using the nisclient script to create credential information.

• Use the nispopulate script. This is an easy method of creating or altering credentials for a one or more principals who already have information on them stored in NIS maps or /etc files. Because of its convenience, this is a recommended method of administering credentials for groups of NIS+ principals. For step by step instructions on using the nispopulate script to create credential information, see.Populating NIS+ Tables.

• Use the nisaddcred command. The section below describes how credentials and credential information are created using nisaddcred.

The nisaddcred Command

The command used to create credential information is nisaddcred.

Note - You can also use the nispopulate and nisclient scripts to create credential information. They, in turn, use the nisaddcred command. These scripts are much easier to use, and more efficient, than the nisaddcred command. Unless your network requires special features, you should use the scripts.

The nisaddcred command creates, updates, and removes LOCAL and DES credential information. To create credential information, you must have create rights to the proper domain's cred table. To update a credential, you must have modify rights to the cred table or, at least, to that particular entry in the cred table. To delete a credential, you must have destroy rights to the cred table or the entry in the cred table.

• To create or update credentials for another NIS+ principal, use:

  For LOCAL credentials

  nisaddcred -p uid -P principal-name local

  
  

  For DES credentials

  nisaddcred -p rpc-netname -P principal-name des

  
  

• To update your own credentials, use:

  For LOCAL credentials

  nisaddcred -local

  
  

  For DES credentials, use:

  nisaddcred des

  
  

• To remove credentials, use:

  nisaddcred -r principal-name

  
  

Related Commands

In addition to the nisaddcred command described in this chapter, two other commands can provide some useful information about credentials:

Table 12-4 Additional Credential-Related Commands

How nisaddcred Creates Credential Information

Use nisaddcred to create LOCAL and DES credential information.

LOCAL Credential Information

When used to create LOCAL credential information, nisaddcred simply extracts the principal user's UID (and GID) from the principal's login record and places it in the domain's cred table.

DES Credential Information

When used to create DES credential information, nisaddcred goes through a two-part process:

1. Forming the principal's Secure RPC netname. A Secure RPC netname is formed by taking the principal's user ID number from the password record and combining it with the domain name (unix.1050@doc.com, for example).

2. Generating the principal's private and public keys.

To encrypt the private key, nisaddcred needs the principal's Secure RPC password. When the nisaddcred command is invoked with the -des argument, it prompts the principal for a Secure RPC password. Normally, this password is the same as the principal's login password. (If it is different, the user will have to perform additional steps when logging in, as described in Secure RPC Password Versus Login Password Problem.)

The nisaddcred command generates a pair of random, but mathematically related 192-bit authentication keys using the Diffie-Hellman cryptography scheme. These keys are called the Diffie-Hellman key-pair, or simply key-pair for short.

One of these is the private key, and the other is the public key. The public key is placed in the public data field of the cred table. The private key is placed in the private data field, but only after being encrypted with the principal's Secure RPC password:

Figure 12-3 How nisaddcred Creates a Principal's Keys

The principal's private key is encrypted as a security precaution because the cred table, by default, is readable by all NIS+ principals, even unauthenticated ones.

The Secure RPC Netname and NIS+ Principal Name

When creating credential information, you will often have to enter a principal's rpc-netname and principal-name. Each has its own syntax:

• Secure RPC netname. A Secure RPC netname is a name whose syntax is determined by the Secure RPC protocol. Therefore, it does not follow NIS+ naming conventions:

  • For users, the syntax is: unix.uid@domain

  • For machines, the syntax is: unix.hostname@domain

  If a Secure RPC netname identifies a user, it requires the user's UID. If it identifies a machine, it requires the machine's host name. (When used with the nisaddcred command it is always preceded by the -p (lowercase) flag.)

  A Secure RPC netname always begins with the unix (all lowercase) prefix and ends with a domain name. However, because it follows the Secure RPC protocol, the domain name does not contain a trailing dot.

• Principal name. An NIS+ principal follows the normal NIS+ naming conventions, but it must always be fully qualified. the syntax is: principal.domain.