Chapter 7 Administering NIS+ Credentials

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

• "How Credentials Work"

• "Credential Versus Credential Information"

• "Authentication Components"

• "How Principals Are Authenticated"

• "The DES Credential in Detail"

• "Where Credential-Related Information Is Stored"

• "The cred Table in Detail"

• "Creating Credential Information"

• "The nisaddcred Command"

• "How nisaddcred Creates Credential Information"

• "The Secure RPC Netname and NIS+ Principal Name"

• "Creating Credential Information for the Administrator"

• "Creating Credential Information for NIS+ Principals"

• "Updating Your Own Credential Information"

• "Removing Credential Information"

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

NIS+ Credentials

NIS+ credentials are used to identify NIS+ users. This chapter assumes that you have an adequate understanding of the NIS+ security system in general, and in particular of the role that credentials play in that system.

For a complete description of NIS+ credential-related commands and their syntax and options, see the NIS+ man pages.

The description of DES credentials in this chapter is applicable to 192-bit Diffie-Hellman DES credentials. While similar, authentication using other key lengths differs in details. When the command line interface is used to manipulate the keys, the differences are transparent to both the user and the system administrator. Use nisauthconf(1M) to display or set the prescribed key lengths.

How Credentials Work

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

The credential/authentication system prevents someone from assuming some other user's identity. That is, it prevents someone with root privileges on one machine from using the su command to assume the identity of a second user who is either not logged in at all or logged in on another machine and then accessing NIS+ objects with the second user's NIS+ access privileges.

NIS+ cannot prevent someone who knows another user's login password from assuming that other user's identity and the other user's NIS+ access privileges. Nor can NIS+ prevent a user with root privileges from assuming the identity of another user who is currently logged in on the same machine.

See Chapter 6, Security Overview, for a description of how NIS+ credentials and authentication work with authorization and access rights to provide security for the NIS+ namespace.

Credential Versus Credential Information

To understand how DES credentials are created and how they work, you need to distinguish between the credential itself and the information that is used to create and verify it.

• Credential information: The data that is used to generate a DES credential and by the server to verify that credential.

• DES credential: The bundle of numbers that is sent by the principal to the server to authenticate the principal. A principal's credential is generated and verified each time the principal makes an NIS+ request. See "The DES Credential in Detail" for a detailed description of the DES credential.

Authentication Components

In order for the credential/authentication process to work the following components must be in place:

• Principal's DES credential information. This information is initially created by an NIS+ administrator for each principal. It is stored in the cred table of the principal's home domain. A principal's DES credential information consists of:

  • Principal name. This would be a user's fully qualified login ID or a machine's fully qualified host name.

  • Principal's Secure RPC netname. Each principal has a unique Secure RPC netname. (See "DES Credential Secure RPC Netname" for more information on Secure RPC netnames.)

  • Principal's public key.

  • Principal's encrypted private key.

• Principal's LOCAL credential

• Server's public keys. Each directory object stores copies of the public keys of all the servers in that domain. Note that each server's DES credentials are also stored in the cred table.

• Keyserver copy of principal's private key. The keyserver has a copy of the private key of the principal that is currently logged in (user or machine).

How Principals Are Authenticated

There are three phases to the authorization process:

• Preparation phase. This consists of the setup work performed by an NIS+ administrator prior to the user logging in; for example, creating credential information for the user.

• Login phase. This consists of the actions taken by the system when a user logs in.

• Request phase. This consists of the actions taken by the software when an NIS+ principal makes a request for an NIS+ service or access to an NIS+ object.

These three phases are described in detail in the following subsections.

Credentials Preparation Phase

The easiest way for an NIS+ administrator to create credential information for users is to use the nisclient script as described in Solaris Naming Setup and Configuration Guide. This section describes how to create client information using the NIS+ command set.

Prior to an NIS+ principal logging in, an NIS+ administrator must create DES credential information for that principal (user or machine). The administrator must:

• Create a public key and an encrypted private key for each principal. These keys are stored in the principal's home domain cred table. This can be done with the nisaddcred command as described in "Creating Credential Information for NIS+ Principals".

• Create server public keys. (See "Updating Public Keys".)

Login Phase--Detailed Description

When a principal logs into the system the following steps are automatically performed:

1. The keylogin program is run for the principal. The keylogin program gets the principal's encrypted private key from the cred table and decrypts it using the principal's login password.

When a principal's login password is different from his or her Secure RPC password, keylogin cannot decrypt it and the user starts getting "cannot decrypt" errors or the command fails without a message. For a discussion of this problem, see "Secure RPC Password Versus Login Password Problem".

1. The principal's decrypted private key is passed to the keyserver which stores it for use during the request phase.

The decrypted private key remains stored for use by the keyserver until the user does an explicit keylogout. If the user simply logs out (or goes home for the day without logging out), the decrypted private key remains stored in the server. If someone with root privileges on a user's machine switched to the user's login ID, that person would then have use of the user's decrypted private key and could access NIS+ objects using the user's access authorization. Thus, for added security, users should be cautioned to perform an explicit keylogout when they cease work. If they also log out of the system, all they need do is log back in when they return. If they do not explicitly log out, they will have to perform an explicit keylogin when they return to work.

Request Phase--Detailed Description

Every time an NIS+ principal requests access to an NIS+ object, the NIS+ software performs a multistage process to authenticate that principal:

1. NIS+ checks the cred table of the object's domain. If:

   • The principal has LOCAL credential information, NIS+ uses the domain information contained in the LOCAL credential to find the principal's home domain cred table where it obtains the information it needs.

   • The principal has no credential information, the rest of the process is aborted and the principal is given the authorization access class of nobody.

2. NIS+ gets the user's DES credential from the cred table of the user's home domain. The encrypted private key is decrypted with the user's password and saved by the keyserver.

3. NIS+ obtains the server's public key from the NIS+ directory object.

4. The keyserver takes the principal's decrypted private key and the public key of the object's server (the server where the object is stored) and uses them to create a common key.

5. The common key is then used to generate an encrypted DES key. To do this, Secure RPC generates a random number which is then encrypted using the common key. For this reason, the DES key is sometimes referred to as the random key or the random DES key.

6. NIS+ then takes the current time of the principal's server and creates a time stamp that is encrypted using the DES key.

7. NIS+ then creates a 15-second window, which is encrypted with the DES key. This window is the maximum amount of time that is permitted between the time stamp and the server's internal clock.

8. NIS+ then forms the principal's DES credential, which is composed of the following:

   • The principal's Secure RPC netname (unix.identifier@domain) from the principal's cred table.

   • The principal's encrypted DES key from the keyserver

   • The encrypted time stamp

   • The encrypted window

9. NIS+ then passes the following information to the server where the NIS+ object is stored:

   • The access request (whatever it might be)

   • The principal's DES credential

   • Window verifier (encrypted), which is the encrypted window plus one

10. The object's server receives this information.

11. The object's server uses the Secure RPC netname portion of the credential to look up the principal's public key in the cred table of the principal's home domain.

12. The server then uses the principal's public key and the server's private key to regenerate the common key. This common key must match the common key that was generated by the principal's private key and the server's public key.

13. The common key is used to decrypt the DES key that arrived as part of the principal's credential.

14. The server decrypts the principal's time stamp with the newly decrypted DES key and verifies it with the window verifier.

15. The server then compares the decrypted and verified time stamp with the server's current time and proceeds as follows:

    1. If the time difference at the server exceeds the window limit, the request is denied and the process aborts with an error message. For example, suppose the time stamp is 9:00am and the window is one minute. If the request is received and decrypted by the server after 9:01am, it is denied.

    2. If the time stamp is within the window limit, the server checks to see if the time stamp is greater than the one previously received from the principal. This ensures that NIS+ requests are handled in the correct order.

       • Requests received out of order are rejected with an error message. For example, if the time stamp is 9:00am and the most recently received request from this principal had a time stamp of 9:02am, the request would be rejected.

       • Requests that have a time stamp equal to the previous one are rejected with an error message. This ensures that a replayed request is not acted on twice. For example, if the time stamp is 9:00am and the most recently received request from this principal also had a time stamp of 9:00am, this request would be rejected.

16. If the time stamp is within the window limit, and greater than the previous request from that principal, the server accepts the request.

17. The server then complies with the request and stores the time stamp from this principal as the most recently received and acted on request.

18. To confirm to the principal that the information received from the server in answer to the request comes from a trusted server, the server encrypts the time stamp with the principal's DES key and sends it back to the principal along with the data.

19. At the principal's end, the returned time stamp is decrypted with the principal's DES key.

    • If the decryption succeeds, the information from the server is returned to the requester.

    • If the decryption fails for some reason, an error message is displayed.

The DES Credential in Detail

The DES credential consists of:

• The principal's Secure RPC netname (see "DES Credential Secure RPC Netname").

• A verification field (see "DES Credential Verification Field").

DES Credential Secure RPC Netname

• Secure RPC netname. This portion of the credential is used to identify the NIS+ principal. Every Secure RPC netname contains three components:

  • Prefix. The prefix is always the word unix.

  • Identifier. If the principal is a client user, the ID field is the user's UID. If the principal is a client workstation, the ID field is the workstation's hostname.

  • Domain name. The domain name is the name of the domain that contains the principal's DES credential (in other words, the principal's home domain).

Remember that an NIS+ principal name always has a trailing dot, and a Secure RPC netname never has a trailing dot.

DES Credential Verification Field

The verification field is used to make sure the credential is not forged. It is generated from the credential information stored in the cred table.

The verification field is composed of:

• The principal's encrypted DES key, generated from the principal's private key and the NIS+ server's public key as described in "Request Phase--Detailed Description"

• The encrypted time stamp

• The time window

How the DES Credential Is Generated

To generate its DES credential, the principal depends on the keylogin command, which must have been executed before the principal tries to generate its credential. The keylogin command (often referred to simply as a keylogin) is executed automatically when an NIS+ principal logs in. See Figure 7-2.

Note that if the principal's login password is different from the principal's Secure RPC password, a successful keylogin cannot be performed. See "Secure RPC Password Versus Login Password Problem" for a discussion of this situation.

The purpose of the keylogin is to give the principal access to the principal's private key. keylogin fetches the principal's private key from the cred table, decrypts it with the principal's Secure RPC password (remember that the private key was originally encrypted with the principal's Secure RPC password), and stores it locally with the keyserver for future NIS+ requests.

Figure 7-1 keylogin Generates a Principal's Private Key

To generate its DES credential, the principal still needs the public key of the server to which it will send the request. This information is stored in the principal's directory object. Once the principal has this information, it can form the verification field of the credential.

First, the principal generates a random DES key for encrypting various credential information. The principal uses its own private key (stored in the keyserver) and the server's public key to generate a common key that is used to generate and encrypt the random DES key. It then generates a time stamp that is encrypted with the DES key and combines it with other credential-related information into the verification field:

Figure 7-2 Creating the DES Credential

Secure RPC Password Versus Login Password Problem

When a principal's login password is different from his or her Secure RPC password, keylogin cannot decrypt it at login time because keylogin defaults to using the principal's login password, and the private key was encrypted using the principal's Secure RPC password.

When this occurs, the principal can log in to the system, but for NIS+ purposes the principal is placed in the authorization class of nobody because the keyserver does not have a decrypted private key for that user. Since most NIS+ environments are set up to deny the nobody class create, destroy, and modify rights to most NIS+ objects, this results in "permission denied" errors when the user tries to access NIS+ objects.

In this context, network password is sometimes used as a synonym for Secure RPC password. When prompted for your "network password," enter your Secure RPC password.

To be placed in one of the other authorization classes, a user in this situation must explicitly run the keylogin program and give the principal's Secure RPC password when keylogin prompts for a password. (See "Keylogin".)

But an explicit keylogin provides only a temporary solution that is good only for the current login session. The keyserver now has a decrypted private key for the user, but the private key in the user's cred table is still encrypted using the user's Secure RPC password, which is different than the user's login password. The next time the user logs in, the same problem recurs. To permanently solve the problem the user needs to re-encrypt the private key in the cred table to one based on the user's login ID rather than the user's Secure RPC password. To do this, the user needs to run chkey -p as described in "Changing Keys for an NIS+ Principal".

Thus, to permanently solve problems related to a difference in Secure RPC password and login password, the user (or an administrator acting for the user) must perform these steps:

1. Log in using the login password.

2. Run the keylogin program to temporarily get a decrypted private key stored in the keyserver and thus gain temporary NIS+ access privileges.

3. Run chkey -p to permanently change the encrypted private key in the cred table to one based on the user's login password.

4. When you are ready to finish this login session, run keylogout.

5. Log off the system with logout.

Cached Public Keys Problems

Occasionally, you might find that even though you have created the proper credentials and assigned the proper access rights, some principal requests still get denied. The most common cause of this problem 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 "The nisupdkeys Command" for information on using the nisupdkeys command and "Stale and Outdated Credential Information" for information on how to correct this type of problem.)

• Killing the nis_cachmgr on your machine, removing /var/nis/NIS_SHARED_DIRCACHE, and then restarting nis_cachemgr.

Where Credential-Related Information Is Stored

This section describes where credential-related information is stored throughout the NIS+ namespace.

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, do not. lists all the objects, tables, and files that store credential-related information and how to reset it.

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

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 14, Administering NIS+ Tables.

The cred table as shown in Table 7-3 has five columns:

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

Administering NIS+ Credential Information

The following sections describe how to use the nisaddcred command to administer existing credential information. You must have create, modify, read, and destroy rights to the cred table to perform these operations.

Updating Your Own Credential Information

Updating your own credential information is considerably easier than creating it. Just type the simple versions of the nisaddcred command while logged in as yourself:

# nisaddcred des
# nisaddcred local

To update credential information for someone else, you simply perform the same procedure that you would use to create that person's credential information.

Removing Credential Information

The nisaddcred command removes a principal's credential information, but only from the local domain where the command is run.

Thus, to completely remove a principal from the entire system, you must explicitly remove that principal's credential information from the principal's home domain and all domains where the principal has LOCAL credential information.

To remove credential information, you must have modify rights to the local domain's cred table. Use the -r option and specify the principal with a full NIS+ principal name:

# nisaddcred -r principal-name

The following two examples remove the LOCAL and DES credential information of the administrator Morena.doc.com. The first example removes both types of credential information from her home domain (doc.com.), the second removes her LOCAL credential information from the sales.doc.com. domain. Note how they are each entered from the appropriate domain's master servers.

rootmaster# nisaddcred -r morena.doc.com.
salesmaster# nisaddcred -r morena.doc.com.

To verify that the credential information was indeed removed, run nismatch on the cred table, as shown below. For more information about nismatch, see Chapter 14, Administering NIS+ Tables.

rootmaster# nismatch morena.doc.com. cred.org_dir
salesmaster# nismatch morena.doc.com. cred.org_dir