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. Part 1 of Solaris Naming Setup and Configuration Guide 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. Part 1 of Solaris Naming Setup and Configuration Guide gives step by step instructions on using the nispopulate script to create credential information.

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

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:

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 7-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 workstation, it requires the workstation'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 workstation, 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.)

Creating Credential Information for the Administrator

When a namespace is first set up, credential information is created first for the administrators who will support the domain. Once they have credential information, they can create credential information for other administrators, client workstations, and client users.

When you try to create your own credential information, you run into a problem of circularity: you cannot create your own credential information unless you have Create rights to your domain's cred table, but if the NIS+ environment is properly set up, you cannot have such rights until you have credentials. You have to step out of the loop somehow. You can do this in one of two ways:

• By creating your credential information while logged in as superuser to your domain's master server

• By having another administrator create your credential information using a dummy password, then changing your password with the chkey command.

In either case, your credential information is thus created by another NIS+ principal. To create your own credential information, follow the instructions in "Creating Credential Information for NIS+ Principals".

Creating Credential Information for NIS+ Principals

Credential information for NIS+ principals can be created any time after their domain has been set up; in other words, once a cred table exists.

To create credential information for an NIS+ principal:

• You must have Create rights to the cred table of the principal's home domain.

• The principal must be recognized by the server. This means that:

  • If the principal is a user, the principal must have an entry either in the domain's NIS+ passwd table or in the server's /etc/passwd file.

  • If the principal is a workstation, it must have an entry either in the domain's NIS+ Hosts table or in the server's

Once those conditions are met, you can use the nisaddcred command with both the -p and -P options:

For LOCAL credentials

nisaddcred -p uid -P principal-name local

For DES credentials

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

Remember these principles:

• You can create both LOCAL and DES credential information for a principal user.

• You can only create DES credential information for a principal workstation.

• You can create DES credential information only in the principal's home domain (user or machine).

• You can create LOCAL credential information for a user in both the user's home domain and in other domains.

For User Principals--Example

This example creates both LOCAL and DES credential information for an NIS+ user named morena who has a UID of 11177. She belongs to the doc.com. domain, so this example enters her credential information from a principal machine of that domain:

client# nisaddcred -p 11177 -P morena.doc.com. local 
client# nisaddcred -p unix.11177@sales.doc.com \
   -P morena.doc.com. des
Adding key pair for unix.11177@sales.doc.com 
   (morena.doc.com.).
Enter login password:

The proper response to the Enter login password: prompt is morena's login password. (If you don't know her login password, you can use a dummy password that she can later change using chkey, as described in the next example.)

Using a Dummy Password and chkey--Example

If you don't know the user's login password, you can use a dummy password as described below.

Table 7-5, shows how another administrator, whose credential information you create using a dummy password, can then use chkey to change his or her own password. In this example, you create credential information for an administrator named Eiji who has a UID of 119. Eiji, whose login ID is eiji, belongs to the root domain, so you would enter his credential information from the root master server which is named rootmaster.

Retype password:
Done.

First, you would create Eiji's credential information in the usual way, but using a dummy login password. NIS+ would warn you and ask you to re-type it. When you did, the operation would be complete. The domain's cred table would contain Eiji's credential information based on the dummy password. The domain's passwd table (or /etc/passwd file), however, would still have his login password entry so that he can log on to the system.

Then, Eiji would log in to the domain's master server, typing his correct login password (since the login procedure checks the password entry in the passwd table or /etc/passwd file). From there, Eiji would first run keylogin, using the dummy password (since a keylogin checks the cred table), and then use the chkey -p command to change the cred entry to the real thing.

Creating in Another Domain--Example

The two previous examples created credential information for a principal user while the principal user was logged in to the master server of the principal's home domain. However, if you have the proper access rights, you can create credential information in another domain. Simply append the domain name to this syntax:

For LOCAL credentials

nisaddcred -p uid -P principal-name local domain-name

For DES credentials

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

The following example first creates LOCAL and DES credential information for an administrator named Chou in her home domain, which happens to be the root domain, then adds her LOCAL credential information to the doc.com domain. Chou's UID is 11155. This command is typed on from the root master server. For simplicity, it assumes you are entering Chou's correct login password.

rmaster# nisaddcred -p 11155 -P chou.doc.com. local
rmaster# nisaddcred -p unix.11155@doc.com -P chou.doc.com. des
Adding key pair for unix.11155@doc.com (chou.doc.com.).
Enter login password: 
rootmaster# nisaddcred -p 11155 -P chou.doc.com. local doc.com.

LOCAL credential information maps a UID to an NIS+ principal name. Although an NIS+ principal that is a client user can have different user IDs in different domains, it can have only one NIS+ principal name. So, if an NIS+ principal such as chou will be logging in from a domain other than her home domain, not only should she have a password entry in that domain, but also a LOCAL credential in that domain's cred table.

For Workstations--Example

This example creates credential information for a principal workstation. Its host name is starshine1 and it belongs to the root domain. Therefore, its credential information is created from the root master server. In this example, you create them while logged in as root to the root master; however, if you already have valid credential information and the proper access rights, you could create them while logged in as yourself.

rootmaster# nisaddcred -p unix.starshine1@doc.com -P starshine1.doc.com. des
Adding key pair for unix.starshine1@doc.com
 (starshine1.doc.com.).
Enter starshine1.doc.com.'s root login password:
Retype password:

The proper response to the password prompt is the principal workstation's superuser password. Of course, you could use a dummy password that would later be changed by someone logged in as superuser to that principal workstation.