System Administration Guide: Naming and Directory Services (NIS+)

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:

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:

For NIS+ 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 in NIS+ – Example

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

Table 12–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.

Table 12–5 Creating NIS+ Administrator Credentials: Command Summary

Tasks 

Commands 

Create LOCAL credential information for Eiji. 

rootmaster# nisaddcred -p 119 -P eiji.doc.com. local



Create DES credential information for Eiji. 

rootmaster# nisaddcred -p unix.119@doc.com -P eiji.doc.com. des

Adding key pair for unix.119@doc.com (eiji.doc.com.).

Type dummy password for Eiji. 

Enter eiji's login password: 

nisaddcred: WARNING: password differs from login passwd 



Re-enter dummy password. 

Retype password:

You tell Eiji the dummy password that you used. 

 

Eiji logs into rootmaster. 

rootmaster% login: eiji

Eiji enters real login password. 

Password:

Eiji gets error message but is allowed to log in anyway. 

Password does not decrypt secret key for unix.119@doc.com.

Eiji runs keylogin. 

rootmaster% keylogin

Eiji types dummy password. 

Password: dummy-password

Eiji runs chkey.

rootmaster% chkey -p

Updating nisplus publickey database

Generating new key for'unix.119@doc.com'.

Eiji types real login password. 

Enter login password:

Eiji re-types real login password. 

 

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 in 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 Credential Information in Another NIS+ 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 NIS+ Machines – Example

This example creates credential information for a principal machine. 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 machine'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 machine.