Related Commands

The commands listed above handle most credential-related administration tasks, but two other commands can provide marginally useful information about credentials:

Table 8-1

Comman d	Description	See
niscat -o	Lists an object's properties. By looking in the Public Key field of the object's server, you can tell whether the object definition is storing a public key.	page 168
niscat	Lists the contents of the Cred table. By looking through the entries, you can tell whether a principal has LOCAL and DES credentials.	page 198

Where Credential-Related Information Is Stored

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

Table 8-2

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 who is currently logged in.	Run keylogin for a client user or keylogin -r for a client 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 coldstart file and restarts the cache manager.

Table 8-2

Item	Stores	To Reset or Change
Coldstart file	A copy of a directory object, which in turn contains copies of its servers' public keys.	In the root master, kill the NIS+ daemon and restart it. The daemon reloads new information into the existing NIS_COLD_START file. In a client, first remove the coldstart and shared directory files from /var/nis, and kill the cache manager. Then re-initialize the client with nisinit -c. The client's trusted server reloads new information into the client's existing coldstart file.
Passwd Table	A user's password or a workstation's superuser password.	Use the nispasswd 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 command, whether logged on as superuser or as yourself, whichever is appropriate.
Passwd Map (NIS)	A user's password or a workstation's superuser password.	Use yppasswd.

The nisaddcred Command

The nisaddcred command creates, updates, and removes LOCAL and DES credentials. To create a credential, 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, 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.

Syntax

To create or update credentials for another NIS+ principal:

  nisaddcred -p uid -P principal-name local
  nisaddcred -p rpc-netname -P principal-name des

To update your own credentials:

  nisaddcred des
  nisaddcred local

To remove credentials:

nisaddcred -r principal-name

Secure RPC Netname vs NIS+ Principal Name When creating credentials, you will often have to enter a principal's rpc-netname and principal-name. It is easy to confuse their syntaxes, so here is an explanation of each.

A secure RPC netname is a name whose syntax is determined by the Secure RPC protocol. Therefore, it does not follow NIS+ naming conventions:

rpc-netname ::= unix.uid@domain |

unix.hostname@domain

It always begins with the unix. prefix and ends with a domain name. However, the domain name does not contain a trailing dot. If it identifies a user, it requires the user's UID. If it identifies a workstation, it requires the workstation's hostname. It is always preceded by the -p (lowercase) flag.

An NIS+ principal follows the normal NIS+ naming conventions, but it must always be fully-qualified:

principal-name ::= 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 to create credentials, it is always preceded by the -P (uppercase) flag. When used to remove credentials, it does not use the -P flag.

A Note About Creating Your Own Credentials

When you try to create your own credentials, you run into a problem of circularity: you cannot create your own credentials unless you have Create rights to your domain's Cred table, but you cannot have such rights until you have credentials. You have to step out of the loop somehow. You can do this in two ways:

• Creating your credentials while logged on as superuser to your domain's master server
• Having another administrator create your credentials using a dummy password, then changing your password with the chkey command.

In either case, you are creating credentials for "another" NIS+ principal. Therefore, to create your own credentials, follow the instructions in the task titled "How to Create Credentials for an NIS+ Principal" on page 127

· How to Create Credentials for an NIS+ Principal

To create credentials for an NIS+ principal, you must have Create rights to the Cred table of the principal's home domain. In addition, that principal must be recognized by the server. This means that if the principal is a user, he or she 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 /etc/hosts file. Once those conditions are met, you can use the nisaddcred command with both the -p and -P options:

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

Remember that although you can create both LOCAL and DES credentials for a client user, you can only create DES credentials for a client workstation. Also, you can create DES credentials only in the client's home domain, but you can create LOCAL credentials for a client user in other domains, in addition to those of his or her home domain. Following are several examples.

This example creates both LOCAL and DES credentials for an NIS+ principal who is a client user named topadmin and has a UID of 11177. This principal belongs to the Sales.Wiz.Com. domain, so this example enters her credentials from another client of that domain:

salesclient# nisaddcred -p 11177 -P topadmin.Sales.Wiz.Com. local salesclient# nisaddcred -p unix.11177@Sales.Wiz.Com \ -P topadmin.Sales.Wiz.Com. des Adding key pair for unix.11177@Sales.Wiz.Com (topadmin.Sales.Wiz.Com.). Enter login password: enter-login-password

The proper response to the login prompt is topadmin's login password or a dummy password that she can later change.

Below is a similar example, but it is more thoroughly commented and shows how another administrator, whose credentials you create, can then use chkey to change his own password. In this example, you create credentials for an administrator named "Bob," who has a UID of 11199. Bob belongs to the root domain, so you would enter his credentials from the root master server.

rootmaster# nisaddcred -p 11199 -P bob.Wiz.Com. local rootmaster# nisaddcred -p unix.11199@Wiz.Com \ -P bob.Wiz.Com. des Adding key pair for unix.11199@Wiz.Com (bob.Wiz.Com.). Enter bob's login password: enter-dummy-password nisaddcred: WARNING: password differs from login passwd. Retype password: re-enter-dummy-password	# Create LOCAL credential for Bob. # Create DES credential for Bob. # # # Enter dummy password for Bob. # # Re-enter dummy password.
% rlogin rootmaster -l bob Password: enter-login-password Password does not decrypt secret key for unix.11199@Wiz.Com. $ keylogin Password: enter-dummy-password $ chkey Updating nisplus publickey database Generating new key for 'unix.11199@Wiz.Com'. Enter login password: enter-login-password Retype password: re-enter-login-password Done.	# Bob logs into rootmaster. # Bob enters real login password. # Bob gets error message but is # allowed to login anyway. # Bob does keylogin. # Bob enters dummy password. # Bob does chkey. # # # Bob enters real login password. # Bob re-enters real login # password.

First, you would create Bob's credentials in the usual way, but using a dummy login password. NIS+ would warn you and ask you to re-enter it. When you did, the operation would be complete. The domain's Cred table would contain Bob's credential information based on the dummy password. The domain's Passwd table (or /etc/passwd file), however, would still have the "correct" entry.

Then, Bob would log into the domain's master server, entering his correct login password (since the login operation checks the password entry in the Passwd table or /etc/passwd file). From there, Bob would first keylogin, using the dummy password (since a keylogin checks the Cred table), and then use the chkey command to change the Cred entry to the real thing.

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

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

This example first creates LOCAL and DES credentials for an administrator named "Betty" in her home domain, which happens to be the root domain, then adds her LOCAL credentials to the "Sales.Wiz.Com." domain. Betty's UID is 11155. This command is entered from the root master server. For simplicity, it assumes you are entering Betty's correct login password.

rootmaster# nisaddcred -p 11155 -P betty.Wiz.Com. local rootmaster# nisaddcred -p unix.11155@Wiz.Com \ -P betty.Wiz.Com. des Adding key pair for unix.11155@Wiz.Com (betty.Wiz.Com.). Enter login password: enter-login-password rootmaster# nisaddcred -p 11155 -P betty.Wiz.Com. local \ Sales.Wiz.Com.

LOCAL credentials map a UID to an NIS+ principal name. Although an NIS+ principal who 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

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

Here is an example that creates credentials for a client workstation. Its hostname is "rootclient1" and it belongs to the root domain. Therefore, its credentials are created from the root master server. In this example, you create them while logged on as root to the root master; however, if you already have valid credentials and the proper access rights, you could create them while logged on as yourself.

rootmaster# nisaddcred -p unix.rootclient1@Wiz.Com \ -P rootclient1.Wiz.Com. des Adding key pair for unix.rootclient1@.Wiz.Com (rootclient1.Wiz.Com.). Enter rootclient1.Wiz.Com.'s root login password: enter-password Retype password: re-enter-password

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

· How to Update Your Own Credentials

Updating your own credentials is considerably simpler than creating them. Simply enter the simple versions of the nisaddcred command while logged on as yourself:

nisaddcred des
nisaddcred local

· How to Remove Credentials

The nisaddcred command removes a principal's credentials, but both at a time and only from the local domain. To use it, you must have Modify rights to the local domain's Cred table. Use the -r option and specify the principal with its NIS+ principal name:

nisaddcred -r principal-name

The following two examples remove the LOCAL and DES credentials of the administrator "topadmin.Wiz.Com." The first example removes both types of credentials from her home domain ("Wiz.Com."), the second removes her LOCAL credentials from the "Sales.Wiz.Com." domain. Note how they are each entered from the appropriate domain's master servers.

rootmaster# nisaddcred -r topadmin.Wiz.Com. salesmaster# nisaddcred -r topadmin.Wiz.Com.

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

rootmaster# nismatch topadmin.Wiz.Com. cred.org_dir salesmaster# nismatch topadmin.Wiz.Com. cred.org_dir

The chkey Command

The chkey command changes an NIS+ principal's public and secret keys stored in the Cred table. It does not affect the principal's entry either in the Passwd table or in the /etc/passwd file. In fact, this command is often used to make a principal's entry in the Cred table correspond to its entry in the Passwd table.

The chkey command interacts with the keyserver, the Cred table, and the Passwd table. When you invoke it, it tries to identify you with the keyserver. Therefore, you must keylogin before using it. However, the keyserver needs the password that was used to generate your keys in the Cred table. That may be different from your normal login password, depending on how your credentials were created.

For all this to work, you must also have an entry in the Passwd table. If you don't have an entry, or if you forget to keylogin, chkey will give you the following error message:

chkey: unable to locate password record for uid uid

Once it identifies you, it prompts you for a new password, which it then uses to generate a new set of public and private keys. It stores those keys in the Cred table, provided you have Modify rights to it.

· How to Change Your DES Keys

To change your DES keys with the chkey command, you need:

• Modify rights to your domain's Cred table
• The password from which your entry in the Cred table was formed
• An entry in the domain's Passwd table.
• Your login password.

First, keylogin, using your current password, then use chkey. Here is an example:

rootmaster% keylogin Password: enter-current-password rootmaster% chkey Updating nisplus publickey database Generating new key for 'unix.11199@Wiz.Com'. Enter login password: enter-new-password Retype password: re-enter-new-password Done.

If you want to use chkey again before you logout, you don't have to keylogin again.

The nispasswd Command

The nispasswd command changes or displays information stored in the NIS+ Passwd table. If you use it to change a principal's actual password, it tries to update the principal's secret key in the Cred table. If you have Modify rights to the Cred table and if the principal's login and network passwords are the same, it will update the keys in the Cred table. Otherwise, it changes the password, but does not change the secret keys. This means that the secret keys in the Cred table will have been formed with a password that is now different from the one stored in the Passwd table. In that case, you'll either have to change the keys with the chkey command, or keylogin after each login.

The Name Service Switch determines which processes obtain the new password. If the source for Password information in the Switch is nisplus, all processes will use the new password. However, if the source is nis or files, processes that use the standard getpwnam and getspnam interfaces (such as rlogin and ftp), will look elsewhere for the password information, and so will not get the new password stored in the NIS+ table. For more information about the Name Service Switch, see Chapter 6, "Setting Up the Name Service Switch."

If you are the owner of the passwd table, provided you have the proper credentials, you can change password information at any time and without constraints. However, if you are not the owner, you must comply with aging and construction constraints.

When you attempt to change a password, if the old password has not aged sufficiently (i.e., number of days since last change is less than min), NIS+ will terminate and not carry out the change.

The new password must have at least six characters, but no more than eight. It must contain at least two letters and at least one number or special character. Make sure the password is not derived in any way from the user's login name. Also make sure the new password has at least three characters that are different from the old password.

To use the nispasswd command, you must have the access rights appropriate for the operation:

Table 8-3 nispasswd

This Operation	Requires These Rights	To This Object
Displaying information	Read	The Passwd entry
Changing Information	Modify	The Passwd entry
Adding New Information	Modify	The Passwd Table

---

Note - nis_passwd is designed to function with credentials. If there are no credentials, nis_passwd cannot work. Systems running at security level 0 do not create or maintain credentials. Thus, in most cases you cannot use nis_passwd on a system running at security level 0. The exception to this rule concerns systems that have previously been run at a higher security level. If

credentials from that period of higher level operation still exist in proper form and format, then you can run nis_passwd for principals holding those credentials even if the system is running at security level 0.

---

Related Commands

The nispasswd command provides capabilities that are similar to those offered by other commands. The table below summarizes their differences. Table 8-4

nispasswd and Related Commands

Command	Description
passwd	Changes information in the workstation's /etc/passwd and /etc/shadow file.
yppasswd	Changes information in the NIS password map. Has no effect on the NIS+ Passwd table.
nispasswd	Changes and displays information in the NIS+ Passwd table. When a principal's password is changed, nispasswd tries to update principal's secret key in the Cred table. Its options are customized for the Passwd tables making the command easier to use for that table than the nistbladm command. It also allows an administrator to lock and force passwords, tasks that nistbladm doesn't allow.
nistbladm	Creates, changes, and displays information about any NIS+ table, including the Passwd table. Although the nispasswd command is easier to use for the Passwd table, nistbladm allows you to: - Create new entries - Delete an existing entry - Change the UID and GID fields in the Passwd table - Change the LastChanged, Inactive, and Expired fields in the Passwd table - Change access rights and other security-related attributes of the Passwd table.
niscat	Can be used to display the contents of the Passwd table.

Syntax

--To display information from the Passwd table

nispasswd -a
nispasswd -d username

--To change a password

nispasswd [username]

--To operate on the Passwd table of another domain

nispasswd [options] -D domainname

· How to Display Password Information

You can use the nispasswd command to display password information about all users in a domain or about one particular user. To display information about all users, use the -a option:

  nispasswd -a

Only the entries and columns for which you have Read permission will be displayed. To display the entry for a particular user, use the -d option. Without a username, it displays your password entry:

  nispasswd -d
  nispasswd -d username

Entries are displayed with the following format:

  username   status   mm/dd/yy   min   max   warn
Table 8-5 NIS+ Password Display Format

Field	Description
username	The user's login name
status	The user's password status. "PS" indicates the account has a password. "LK" indicates the account is locked. "NP" indicates the account has no password.
mm/dd/yy	The date, using Greenwich Mean Time, that the user's password was last changed.

Field	Description
min	The minimum number of days since the last change that must pass before the password can be changed again.
max	The maximum number of days since the last change that can pass before the password must be changed.
warn	The number of days' notice that a user is given before his or her password expires.

To display entries from a passwd table in another domain, use the -D option:

nispasswd -a -D domainname
nispasswd -d username -D domainname

· How to Change Passwords

To change your own password, enter the nispasswd command without any arguments:

  nispasswd

To change the password of another user in the local domain, add a username:

  nispasswd username

To change the password of another user in a remote domain, also add the -D flag:

nispasswd username -D domainname

NIS+ prompts you once for the old password and twice for the new one. If you are the owner of the Passwd table, NIS+ does not prompt you for the old password. If you make a mistake and the two entries for the new password don't match, NIS+ will ask you again for the new password.

The nisupdkeys Command

The public keys of NIS+ servers are stored in several locations throughout the namespace, as listed in Table 8-2 on page 124. When new credentials are created for the server, a new public key is generated and stored in the Cred table. However, the directory object still has a copy of the old public key. The nisupdkeys command is used to update that copy.

The nisupdkeys command can update the key of one particular server, or of all the servers that support a directory. It can also update the server's IP address, if that has changed, and it can remove the server's public key from the directory object. However, it cannot update the NIS_COLD_START files on the client workstations. To update their copy, the clients should invoke the nisinit command. Or, if the NIS+ cache manager is running and more than one server is available in the coldstart file, they can wait until the time-to-live expires on the directory object. When that happens, the cache manager automatically updates the coldstart file. The default time-to-live is 12 hours.

To use the nisupdkeys command, you must have Modify rights to the directory object.

Syntax

Note that the nisupdkeys command is located in /usr/lib/nis.

--To update keys:

/usr/lib/nis/nisupdkeys [ directory ]
/usr/lib/nis/nisupdkeys -H server-name

--To update IP addresses:

/usr/lib/nis/nisupdkeys -a [ directory ]
/usr/lib/nis/nisupdkeys -a -H server-name

--To clear keys:

/usr/lib/nis/nisupdkeys -C [ directory ]
/usr/lib/nis/nisupdkeys -C -H server-name

--To display a list of directories served by a server

/usr/lib/nis/nisupdkeys -s [-a|-C] -H servername

When a directory name is supplied, nisupdkeys updates the public keys of all the servers that support that directory. If the name of a server is supplied instead, it updates the public keys of that server only. If no directory name is supplied, it updates the public keys of the local directory.

· How to Update All Public Keys in a Directory

To update the public keys of all servers that support a particular directory, simply provide the directory name:

nisupdkeys directory

If you don't supply a directory name, it uses the local directory. These two examples update the public keys of the root directory and a directory beneath it. They are both entered from the root master:

rootmaster# /usr/lib/nis/nisupdkeys Fetch Public key for server rootmaster.Wiz.Com. netname= 'unix.rootmaster@Wiz.Com' Updating rootmaster.Wiz.Com.'s public key. Public key : public-key rootmaster# /usr/lib/nis/nisupdkeys Sales.Wiz.Com.

· How to Update Keys of a Particular Server

To update the public keys of a particular server in all the directories that store them, use the -H option and provide the server name:

nisupdkeys -H server-name

· How to Clear Public Keys

To clear all the public keys stored by a directory, use the -C option and specify the directory. To clear the public keys of only one server supporting that directory, use the -C and -H options.

nisupdkeys -C directory
nisupdkeys -C -H server-name

· How to Update IP Addresses

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

nisupdkeys -a directory
nisupdkeys -a -H server-name

The keylogin Command

The keylogin command helps authenticate an NIS+ principal. When a principal logs in, the login process prompts for a password, which is used to authenticate the principal. Normally, this is the only time the principal is asked to provide a password. However, if the principal's DES credentials were created with a password that is different from the login password, the login password will no longer be able to authenticate the principal.

To remedy this problem, the principal must perform a keylogin, using the keylogin command, after every login. The keylogin command prompts the principal for its network password and stores it in the key server. From there, it is used by all NIS+ processes to authenticate the principal.

Syntax

keylogin
keylogin -r

The -r flag is used to keylogin a client workstation and to store the superuser's key in /etc/.rootkey.

· How to Keylogin

To keylogin, simply enter the keylogin command and, when prompted, supply your network password; i.e., the password used to create your DES credentials. Before logging out, use the keylogout command. This example shows how to keylogin for a client user and a client workstation:

Client1% login: login-name Password: login-password Client1% keylogin Password: network-password Client1% su Password: superuser-password Client1# keylogin -r Password: superuser-network-password Wrote secret key into /etc/.rootkey