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
NIS+ Principal Name | Authentication Type | Authentication Name | Public Data | Private Data | |
|---|---|---|---|---|---|
Column Name | cname | auth_type | auth_name | public_data | private_data |
User | Fully qualified principal name | LOCAL | UID | GID list |
|
Machine | Fully qualified principal name | DES | Secure RPC netname | Public key | Encrypted Private key |
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
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
Command | Description | See |
|---|---|---|
niscat -o | Lists a directory's properties. By looking in the public key field of the directory's server, you can tell whether the directory object is storing a public key. | |
nismatch- | When run on the cred table, displays credential information for principal. |
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:
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).
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.
Whether it identifies a client user or a client machine, it begins with the principal's name, followed by a dot and the complete domain name, ending in a dot. (When used with nisaddcred to create credential information, it is always preceded by the -P (uppercase) flag. When used to remove credential information, it does not use the -P flag.)