Chapter 13 Administering NIS+ Keys

This chapter describes NIS+ keys and how to administer them.

Some NIS+ security tasks can be performed more easily with Solstice AdminSuite tools if you have them available.

NIS+ might not be supported in a future release. Tools to aid the migration from NIS+ to LDAP are available in the Solaris 9 operating environment (see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)). For more information, visit http://www.sun.com/directory/nisplus/transition.html.

NIS+ Keys

NIS+ keys are used to encrypt NIS+ related information.

This chapter assumes that you have an adequate understanding of the NIS+ security system in general, and in particular of the role that keys play in that system (see Chapter 11, NIS+ Security Overview, for this information).

For a complete description of NIS+ key-related commands and their syntax and options, see the NIS+ man pages. (The nisaddcred command also performs some key-related operations. See Chapter 12, Administering NIS+ Credentials for more information.)

Keylogin

When a principal logs in, the login process prompts for a password. That password is used to pass the user through the login security gate and give the user access to the network. The login process also decrypts the user's private key stored in the user's home domain cred table and passes that private key to the keyserver. The keyserver then uses that decrypted private key to authenticate the user each time the user accesses an NIS+ object.

Normally, this is the only time the principal is asked to provide a password. However, if the principal's private key in the cred table was encrypted with a password that was different from the user's login password, login cannot decrypt it using the login password at login time, and thus cannot provide a decrypted private key to the keyserver. (This most often occurs when a user's private key in the cred table was encrypted with a Secure RPC password different from the user's login password.)

In this context, network password is sometimes used as a synonym for Secure RPC password.

To temporarily remedy this problem, the principal must perform a keylogin, using the keylogin command, after every login. (The -r flag is used to keylogin the superuser principal and to store the superuser's key in /etc/.rootkey on a host.)

For a principal user

keylogin

For a principal machine (only once)

keylogin -r

Note, however, that performing an explicit keylogin with the original password provides only a temporary solution good for the current login session only. The private key in the cred table is still encrypted with a password different than the user's login password so the next time the user logs in the problem will reoccur. To permanently solve this problem, the user must run chkey to change the password used to encrypt the private key to the user's login password (see Changing Keys for an NIS+ Principal).

Changing Keys for an NIS+ Principal

The chkey command changes an NIS+ principal's public and private keys that are stored in the cred table. It does not affect the principal's entry either in the passwd table or in the /etc/passwd file.

The chkey command:

• Generates new keys and encrypts the private key with the password. Run chkey with the -p option to re-encrypt the existing private key with a new password.

• Generates a new Diffie-Hellman key pair and encrypts the private key with the password you provide. (Multiple Diffie-Hellman key pairs can exist for each principal.) In most cases, however, you do not want a new keypair, you want to re-encrypt your current existing private key with the new password. To do this, run chkey with the -p option.

See the man pages for more information on these subjects.

In an NIS+ environment, when you change your login password with any of the current administration tools or the passwd (or nispasswd) commands, your private key in the cred table is automatically re-encrypted with the new password for you. Thus, you do not need to explicitly run chkey after a change of login password.

The chkey command interacts with the keyserver, the cred table, and the passwd table. In order to run chkey, you:

• Must have an entry in the passwd table of your home domain. Failure to meet this requirement will result in an error message.

• Must run keylogin to make sure that the keyserver has a decrypted private key for you.

• Must have modify rights to the cred table. If you do not have modify rights you will get a “permission denied” type of error message.

• Must know the original password with which the private key in the cred table was encrypted. (In most cases, this your Secure RPC password.)

To use the chkey command to re-encrypt your private key with your login password, you first run keylogin using the original password, and then use chkey -p, as shown in Table 13–1 ,which illustrates how to perform a keylogin and chkey for a principal user:

Sirius% chkey -p
Updating nisplus publickey database
Updating new key for 'unix.1199@Doc.com'.

Changing the Keys

The following sections describe how to change the keys of an NIS+ principal.

Whenever you change a server's keys, you must also update the key information of all the clients in that domain as explained in Updating Client Key Information.

Changing Root Keys From Root

Table 13–2, shows how to change the keys for the root master server from the root master (as root):

rootmaster#
nisaddcred des

Where:

• pid is the process ID number reported by the ps -e | grep rpc.nisd command.

• dirs are the directory objects you wish to update. (That is, the directory objects that are served by rootmaster.)

In the first step of the process outlined in Table 13–2, nisaddcred updates the cred table for the root master, updates /etc/.rootkey and performs a keylogin for the root master. At this point the directory objects served by the master have not been updated and their credential information is now out of synch with the root master. The subsequent steps described in Table 13–2 are necessary to successfully update all the objects.

Whenever you change a server's keys, you must also update the key information of all the clients in that domain as explained in Updating Client Key Information.

Changing Root Keys From Another Machine

To change the keys for the root master server from some other machine you must have the required NIS+ credentials and authorization to do so.

Where:

• principal is the root machine's Secure RPC netname. For example: unix.rootmaster@doc.com (no dot at the end).

• nis-principal is the root machine's NIS+ principal name. For example, rootmaster.doc.com. (a dot at the end).

• dirs are the directory objects you want to update (that is, the directory objects that are served by rootmaster).

When running nisupdkeys be sure to update all relevant directory objects at the same time. In other words, do them all with one command. Separate updates may result in an authentication error.

Whenever you change a server's keys, you must also update the key information of all the clients in that domain as explained in Updating Client Key Information.

Changing the Keys of a Root Replica From the Replica

To change the keys of a root replica from the replica, use these commands:

replica# nisaddcred des
replica# nisupdkeys dirs

Where:

• dirs are the directory objects you wish to update, (that is, the directory objects that are served by replica).

When running nisupdkeys be sure to update all relevant directory objects at the same time. In other words, do them all with one command. Separate updates may result in an authentication error.

Whenever you change a server's keys, you must also update the key information of all the clients in that domain as explained in Updating Client Key Information.

Changing the Keys of a Nonroot Server

To change the keys of a nonroot server (master or replica) from the server, use these commands:

subreplica# nisaddcred des
subreplica# nisupdkeys parentdir dirs

Where:

• parentdir is the non-root server's parent directory (that is, the directory containing subreplica's NIS+ server).

• dirs are the directory objects you want to update (that is, the directory objects that are served by subreplica).

When running nisupdkeys be sure to update all relevant directory objects at the same time. In other words, do them all with one command. Separate updates may result in an authentication error.

Whenever you change a server's keys, you must also update the key information of all the clients in that domain, as explained in Updating Client Key Information.

Updating Public Keys

The public keys of NIS+ servers are stored in several locations throughout the namespace. When new credential information is created for the server, a new key pair is generated and stored in the cred table. However, namespace directory objects still have copies of the server's old public key. The nisupdkeys command is used to update those directory object copies.

The nisupdkeys Command

If a new keypair is generated because the old key pair has been compromised or the password used to encrypt the private key is forgotten, the nisupdkeys can be used to update the old public key in the directory objects.

The nisupdkeys command can:

• Update the key of one particular server

• Update the keys of all the servers that support an NIS+ directory object

• Remove a server's public key from the directory object

• Update a server's IP address, if that has changed

However, nisupdkeys cannot update the NIS_COLD_START files on the principal machines. To update their copies of a server's keys, NIS+ clients should run the nisclient command. Or, if the NIS+ cache manager is running and more than one server is available in the coldstart file, the principals can wait until the time-to-live expires on the directory object. When that happens, the cache manager automatically updates the cold-start file. The default time-to-live is 12 hours.

To use the nisupdkeys command, you must have modify rights to the NIS+ directory object.

Updating Public Keys Arguments and Examples

The nisupdkeys command is located in /usr/lib/nis. The nisupdkeys command uses the following arguments (for a complete description of the nisupdkeys command and a full list of all its arguments, see the nisupdkeys man page):

Table 13–5 gives an example of updating a public key:

Updating IP Addresses

If you change a server's IP address, or add additional addresses, you need to run nisupdkeys to update NIS+ address information.

To update the IP addresses of one or more servers, use the nisupdkeys command -a option.

To update the IP addresses of servers of a given domain

rootmaster# nisupdkeys -a domain

To update the IP address of a particular server

rootmaster# nisupdkeys -a -H server

Updating Client Key Information

Whenever you change any server's keys, you must update all of the clients as well. Remember, that all NIS+ servers are also NIS+ clients, so if you update the keys on one server, you must update key information on all other machines in the domain regardless of whether or not they are NIS+ servers or ordinary clients.

There are three ways to update client key information:

• The easiest way to update an individual client's key information is by running the nisclient script on the client.

• Another way to update an individual client's key information is by running the nisinit command on the client as described in Initializing a Client.

• You can globally update client key information for all the machines in a domain by shortening the Time To Live value of the domain's directory object as explained in Globally Updating Client Key Information.

Globally Updating Client Key Information

After changing a server's keys, you can globally update client key information for all the machines in a domain by:

1. Use the nischttl command to reduce the Time To Live (TTL) value of the domain's directory object so that the value expires almost immediately.

   For example, if you have changed the keys for a server in the sales.doc.com. domain, to reduce the directory's TTL value to one minute you would enter:

   client% nischttl 60 sales.doc.com.

2. When the directory's TTL value expires, the cache manager expires the entry and then obtains the new, updated information for clients.

3. Once the directory object's TTL value has expired, reset the directory object's TTL to its default value.

   For example, to reset the TTL value to 12 hours for the sales.doc.com. domain's directory object, you would enter:

   client% nischttl 12h sales.doc.com.

   See The nischttl Command for more information on working with TTL values.