Solaris Naming Administration Guide

Stale and Outdated Credential Information

Occasionally, you may find that even though you have created the proper credentials and assigned the proper access rights, some client requests still get denied. This may be due to out-of-date information residing somewhere in the namespace.

Storing and Updating Credential Information

Credential-related information, such as public keys, is stored in many locations throughout the namespace. NIS+ updates this information periodically, depending on the time-to-live values of the objects that store it, but sometimes, between updates, it gets out of sync. As a result, you may find that operations that should work, don't work. Table A-2 lists all the objects, tables, and files that store credential-related information and how to reset it.

Table A-2 Where Credential-Related Information is Stored


Item	Stores	To Reset or Change
cred table	NIS+ principal's secret key and public key. These are the master copies of these keys.	Use `nisaddcred` to create new credentials; it updates existing credentials. An alternative is `chkey`.
Directory object	A copy of the public key of each server that supports it.	Run the `/usr/lib/nis/` `nisupdkeys` command on the directory object.
Keyserver	The secret key of the NIS+ principal that is currently logged in.	Run `keylogin` for a principal user or `keylogin` `-r` for a principal workstation.
NIS+ daemon	Copies of directory objects, which in turn contain copies of their servers' public keys.	Kill the daemon and the cache manager. Then restart both.
Directory cache	A copy of directory objects, which in turn contain copies of their servers' public keys.	Kill the NIS+ cache manager and restart it with the `nis_cachemgr` `-i` command. The `-i` option resets the directory cache from the cold-start file and restarts the cache manager.
Cold-start file	A copy of a directory object, which in turn contains copies of its servers' public keys.	On the root master, kill the NIS+ daemon and restart it. The daemon reloads new information into the existing `NIS_COLD_START` file. For a client, first remove the cold-start and shared directory files from `/var/nis`, and kill the cache manager. Then re-initialize the principal with `nisinit` `-c`. The principal's trusted server reloads new information into the principal's existing cold-start file.
passwd table	A user's password or a workstation's superuser password.	Use the `passwd -r nisplus` command. It changes the password in the NIS+ passwd table and updates it in the cred table.
`passwd` file	A user's password or a workstation's superuser password.	Use the `passwd -r nisplus` command, whether logged in as superuser or as yourself, whichever is appropriate.
`passwd` map (NIS)	A user's password or a workstation's superuser password.	Use `passwd -r nisplus`.

Updating Stale Cached Keys

The most commonly encountered out-of-date information is the existence of stale objects with old versions of a server's public key. You can usually correct this problem by running nisupdkeys on the domain you are trying to access. (See Chapter 7, Administering NIS+ Credentials, for information on using the nisupdkeys command.)

Because some keys are stored in files or caches, nisupdkeys cannot always correct the problem. At times you might need to update the keys manually. To do that, you must understand how a server's public key, once created, is propagated through namespace objects. The process usually has five stages of propagation. Each stage is described below.

Stage 1: Server's Public Key Is Generated

An NIS+ server is first an NIS+ client. So, its public key is generated in the same way as any other NIS+ client's public key: with the nisaddcred command. The public key is then stored in the cred table of the server's home domain, not of the domain the server will eventually support.

Stage 2: Public Key Is Propagated to Directory Objects

Once you have set up an NIS+ domain and an NIS+ server, you can associate the server with a domain. This association is performed by the nismkdir command. When the nismkdir command associates the server with the directory, it also copies the server's public key from the cred table to the domain's directory object. For example, assume the server is a client of the doc.com. root domain, and is made the master server of the sales.doc.com. domain.

Figure A-1 Public Key is Propagated to Directory Objects

Its public key is copied from the cred.org_dir.doc.com. domain and placed in the sales.doc.com. directory object. This can be verified with the niscat -o sales.doc.com. command.

Stage 3: Directory Objects Are Propagated Into Client Files

All NIS+ clients are initialized with the nisinit utility or with the nisclient script.

Among other things, nisinit (or nisclient) creates a cold-start file /var/nis/NIS_COLDSTART. The cold-start file is used to initialize the client's directory cache /var/nis/NIS_SHARED_DIRCACHE. The cold-start file contains a copy of the directory object of the client's domain. Since the directory object already contains a copy of the server's public key, the key is now propagated into the cold-start file of the client.

In addition when a client makes a request to a server outside its home domain, a copy of the remote domains directory object is stored in the client's NIS_SHARED_DIRCACHE file. You can examine the contents of the client's cache by using the nisshowcache command, described on page 184.

This is the extent of the propagation until a replica is added to the domain or the server's key changes.

Stage 4: When a Replica is Added to the Domain

When a replica server is added to a domain, the nisping command (described on page 185) is used to download the NIS+ tables, including the cred table, to the new replica. Therefore, the original server's public key is now also stored in the replica server's cred table.

Stage 5: When the Server's Public Key Is Changed

If you decide to change DES credentials for the server (that is, for the root identity on the server), its public key will change. As a result, the public key stored for that server in the cred table will be different from those stored in:

The cred table of replica servers (for a few minutes only)
The main directory object of the domain supported by the server (until its time-to-live expires)
The NIS_COLDSTART and NIS_SHARED_DIRCACHE files of every client of the domain supported by server (until their time-to-live expires, usually 12 hours)
The NIS_SHARED_DIRCACHE file of clients who have made requests to the domain supported by the server (until their time-to-live expires)

Most of these locations will be updated automatically within a time ranging from a few minutes to 12 hours. To update the server's keys in these locations immediately, use the commands:

Table A-3 Updating a Server's Keys


Location	Command	See
Cred table of replica servers (instead of using `nisping`, you can wait a few minutes until the table is updated automatically)	`nisping`	"The `nisping` Command "
Directory object of domain supported by server	`nisupdkeys`	"The `nisupdkeys` Command"
`NIS_COLDSTART` file of clients	`nisinit` `-c`	"The `nisinit` Command "
`NIS_SHARED_DIRCACHE` file of clients	`nis_cachemgr`	"The `nis_cachemgr` Command "

Note -

You must first kill the existing nis_cachemgr before restarting nis_cachemgr.