Sun Microsystems, Inc.
spacerspacer
spacer www.sun.com docs.sun.com |
spacer
black dot
 
 
  Previous   Contents   Next 
   
 
Chapter 14

Administering Enhanced Security Credentials


Note - 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 Part V). For more information, visit http://www.sun.com/directory/nisplus/transition.html.


Diffie-Hellman Extended Key

NIS+ offers increased security at the RPC(3N) layer beyond 192 bit Diffie-Hellman (RPC(3N) security flavor AUTH_DES) using the RPCSEC_GSS RPC(3N) security flavor. See the nisauthconf(1M) command for a list of which security mechanisms are available on the system. Along with more stringent cryptographic strength, these security mechanisms also provide integrity for each NIS+ transaction. That is, the data for each NIS+ transaction is verified that it has not been modified.

System administraters can take advantage of the more stringent security mechanisms either by running nisauthconf(1M) before the NIS+ server environment is constructed or after, using the guidelines below.

Transitioning to a New Public Key-based Security Mechanism

The more stringent security mechanisms of the public key cryptography family such as Diffie Hellman 640 bit (dh640-0) will require new credentials for each principal to be added to the existing cred table. The procedure outlined below is for a system currently running with Diffie-Hellman 192 bit (RPC security flavor AUTH_DES) security that will be converted to running with Diffie-Hellman 640 bit (RPC security flavor RPCSEC_GSS) security. Although this transition document highlights the most likely case, the principles are the same for converting from any one security mechanism type of the public key cryptography family to another security mechanism of the public key cryptography family.


Note - The following example assumes that $PATH includes /usr/lib/nis.


Configuring NIS+ Security Mechanisms

NIS+ security configuration is done with the nisauthconf(1M) command. nisauthconf takes a list of security mechanisms in order of preference. A security mechanism may use one or more authentication flavors specified in secure_rpc(3N). If des is the only specified mechanism, then NIS+ only uses AUTH_DES for authentication with other NIS+ clients and servers. Any other security mechanisms after des will be ignored by NIS+, except for nisaddcred(1M).

nisauthconf [-v] [mechanism, ...]

Where mechanism is a RPC security mechanism that is available on the system. See nisauthconf(1M) for the list of mechanisms available. If no mechanisms are specified, then a list of currently configured mechanisms is printed.

Creating New Security Mechanism Credentials

Credential information for the new mechanism must be created for each NIS+ user and host principal. In order to do this, on one of the machines running NIS+, the nisauthconf(1M) command must be run to allow the creation of new credentials while the system continues to authenticate with the current mechanism. Also see "Creating Credential Information for NIS+ Principals" for details on credential creation basics.

New Security Mechanism Credentials -Example

Converting des to dh640-0; the nisauthconf should be run as root and the nisaddcred should be run as any principal that has Create rights in the principal's home directory. The server is named server1 and the user principal is named morena. User morena has UID 11177.

client# nisauthconf des dh640-0
client% nisaddcred -P server1.doc.com. -p unix.server1@doc.com dh640-0
      (screen notices not shown) 
client% nisaddcred -P morena.doc.com. -p unix.11177@doc.com -ldummy-password dh640-0
      (screen notices not shown) 

Adding New Keys to NIS+ Directory Objects

Once the new credentials have been generated for all the servers, run nisupdkeys(1m) to add the new public keys to all the directory objects served by these servers. To use the nisupdkeys(1m) command, you must have modify rights to the NIS+ directory object. See "Updating Public Keys" for more details.


Caution - All servers that serve these NIS+ directories and all clients that access these directories must be running Solaris 7 or later.


Adding New Public Keys to NIS+ Directory Objects--Example

In this example, the directories that are being served by the servers with new public keys are doc.com, org_dir.doc.com., groups_dir.doc.com.. The update will be done as the master server principal. Before running the new mechanism, nisupdkeys needs to be configured with nisauthconf(1M). In this example, the current authentication mechanism is des and the new mechanism is dh640-0.

masterserver#	nisauthconf dh640-0 des
masterserver#	nisupdkeys doc.com.
			(screen notices not shown)
masterserver#  nisupdkeys org_dir.doc.com.
			(screen notices not shown)
masterserver#	nisupdkeys groups_dir.doc.com.
			(screen notices not shown)

Configuring NIS+ Servers to Accept New Security Mechanism Credentials

On each server, configure NIS+ authentication so that it accepts both the old and new credentials. This will require running nisauthconf(1m) and keylogin(1) and restarting keyserv(1m). The keylogin(1) command stores the keys for each mechanism in the /etc/.rootkey. See "Keylogin" for basic keylogin details.

Configuring NIS+ Servers to Accept New Security Mechanism Credentials--Example

In this example, the current authentication mechanism is des and the new mechanism is dh640-0. Note the ordering is significant here; any mechanisms after the des entry will be ignored for client and server NIS+ authentication.

server# nisauthconf dh640-0 des
server# keylogin -r
		(screen notices not shown)
server# /etc/reboot

Configuring Machines to Use New Security Mechanism Credentials

Now that the servers can accept the new credentials, the machines can be converted to authenticate via the new credentials. To do this, run nisauthconf(1M) and keylogin(1) as root and reboot.

Configuring Machines to Use New Security Mechanism Credentials--Examples

In this example, the new mechanism is dh640-0 but the system will also attempt authentication with des credentials if the dh640-0 ones are not available or do not succeed.

workstation# nisauthconf dh640-0 des
workstation#  keylogin -r
		(screen notices not shown)
workstation# /etc/reboot

In the next example, the new mechanism is dh640-0 and authentication will only be attempted with this mechanism. Before configuring any system to authenticate via the new mechanism exclusively, the cached directory objects must be refreshed to include the keys for the new mechanism. This can be verified with nisshowcache(1M) . An alternative to waiting for the cached directory objects to time out and be refreshed in the following: kill nis_cachemgr(1M) , then construct a new NIS_COLD_START with nisinit(1M) and then restart niscachemgr(1M).

Manually Refresh Directory Objects--Example NETNAMER

To manually refresh directory objects:

# pkill -u 0 nis_cachemgr
# nisinit -cH masterserver
# niscachemgr -i

Caution - The machine principal and all users of this machine must have dh640-0 credentials in the cred table before the system can be configured to authenticate exclusively with dh640-0.


workstation# nisauthconf dh640-0
workstation#  keylogin -r
		(screen notices not shown)
workstation# /etc/reboot

Changing the Password Protecting New Credentials

For each user given new credentials with the dummy passwd, they need to run chkey(1) to convert to their login password. For more information, see "Changing Keys for an NIS+ Principal".

Change Password Protecting New Credentials--Example

Run chkey(1) to convert to your login password:

# chkey -p
		(screen notices not shown)

Configuring Servers to Accept only New Security Mechanism Credentials

When converting from a lower grade security mechanism to a higher one, the maximum security benefit is achieved by configuring the NIS+ servers to only accept credentials of the new higher grade security mechanism type. Do this only after the servers have been successfully configured to authenticate via the old and the new mechanism.

Before configuring any system to authenticate via the new mechanism exclusively, the cached directory objects must be refreshed to include the keys for the new mechanism and verified with nisshowcache(1M) .

Configuring Servers to Accept only New Security Mechanism Credentials--Example

Run nisauthconf(1m) on each NIS+ server and reboot. In this example, the NIS+ server will be configured to only accept authentication of dh640-0 credentials.

server#  nisauthconf dh640-0
server# /etc/reboot

Optionally, the directory objects can now be updated to remove the old public keys. This should be done from the master server and nisupdkeys(1m) should be run once for each directory served by the servers authenticating only with the new security mechanism. In this example, the directories to be updated are doc.com, org_dir.doc.com., and groups_dir.doc.com..

masterserver#	nisupdkeys doc.com.
			(screen notices not shown)
masterserver#  nisupdkeys org_dir.doc.com.
			(screen notices not shown)
masterserver#	nisupdkeys groups_dir.doc.com.

Removing Old Credentials from the cred Table

If desired, the credentials of the old security mechanism can be removed from the cred table. You must have modify rights to the local domain's cred table. See "Removing Credential Information" for more details.

Removing old Credentials from the cred Table--Example

In this example, the principal morena.doc.com will have her des credentials removed from the cred table.

master# nisaddcred -r morena.doc.com. dh192-0
 
 
 
  Previous   Contents   Next