Chapter 22 Configuring SEAM

This chapter provides configuration procedures for network application servers, NFS servers and SEAM clients. Many of these procedures require root access, so they should be used by System Administrators or advanced users.

• "SEAM Administration Task Map"

• "Configuring SEAM Clients"

• "Configuring SEAM NFS Servers Task Map"

• "Synchronizing Clocks Between KDCs and SEAM Clients"

• "SEAM Client Error Messages"

SEAM Administration Task Map

This table lists the administration tasks required for the Solaris 8 version of SEAM. These procedures require that a KDC with an admin server is installed.

Configuring SEAM Clients

SEAM clients include any host, not a KDC server, on the network that needs to use SEAM services. This section provides a procedure for installing a SEAM client, as well as specific information about using root authentication to mount NFS file systems.

There are two procedures which can be used to configure a SEAM client. "How to Finish the Configuration of a SEAM Client" provides information for configuring a SEAM client that has been partially setup during the installation of the system."How to Configure a SEAM Client" provides the steps for configuring a SEAM client where no configuration of SEAM was attempted during the installation of the Solaris 8 release.

How to Configure a SEAM Client

The following configuration parameters are used:

realm name = ACME.COM




DNS domain name = acme.com




master KDC = kdc1.acme.com




slave KDC = kdc2.acme.com




client = client.acme.com




admin principal = kws/admin




user principal = mre

1. Prerequisites for configuring a SEAM client.

   A KDC with an admin server must be configured and running. In addition, DNS must be installed and the /etc/resolv.conf file should be configured properly.

2. Become superuser on the client.

3. Edit the PAM configuration file (pam.conf).

   Remove the comments from the last eight lines to enable the Kerberos PAM module.

   client1 # tail -11 /etc/pam.conf # # Support for Kerberos V5 authentication (uncomment to use Kerberos) # rlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass login auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass dtlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass other auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass dtlogin account optional /usr/lib/security/$ISA/pam_krb5.so.1 other account optional /usr/lib/security/$ISA/pam_krb5.so.1 other session optional /usr/lib/security/$ISA/pam_krb5.so.1 other password optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass

4. Edit the NFS security service configuration file (nfssec.conf).

   Remove the comments from the lines describing the Kerberos services.

   client1 # cat /etc/nfssec.conf . . # # Uncomment the following lines to use Kerberos V5 with NFS # krb5 390003 kerberos_v5 default - # RPCSEC_GSS krb5i 390004 kerberos_v5 default integrity # RPCSEC_GSS default 1 - - - # default is AUTH_SYS

5. Edit the Kerberos configuration file (krb5.conf).

   To change the file from the default version, you need to change the realm names and the names of the servers.

   client1 # cat /etc/krb5/krb5.conf [libdefaults] default_realm = ACME.COM [realms] ACME.COM = { kdc = kdc1.acme.com kdc = kdc2.acme.com admin_server = kdc1.acme.com } [domain_realm] .acme.com = ACME.COM

6. (Optional) Synchronize with the master KDC's clock using NTP or another clock synchronization mechanism.

   See "Synchronizing Clocks Between KDCs and SEAM Clients" for information about NTP.

7. Add new principals.

   Using the administration tool provided with your KDC add new principals for the client.

   1. Create the NFS service principal.

      Create a principal named: nfs/client1.acme.com.

   2. Create a root principal.

      Create a principal named: root/client1.acme.com.

   3. Create a host principal.

      Create a principal named: host/client1.acme.com.

   4. Add the root principal to the keytab file.

      Make sure that the root/client1.acme.com principal is included in the keytab file.

8. If you want the client to warn users about Kerberos ticket expiration, configure an entry in the /etc/krb5/warn.conf file.

   See warn.conf(4) for more information.

How to Finish the Configuration of a SEAM Client

To configure a SEAM client, after a partial installation has been done when installing the client, follow the instructions in "How to Configure a SEAM Client". Because the installation has been started, verify the contents of pam.conf, nfssec.conf, and krb5.conf instead of editting them.

Configuring SEAM NFS Servers Task Map

NFS services use UNIX UIDs to identify a user and cannot directly use principals. To translate the principal to a UID, a credential table that maps user principals to UNIX UIDs must be created. The procedures below focus on the tasks necessary to configure a SEAM NFS server, administer the credential table, and to initiate Kerberos security modes for NFS-mounted file systems. The following table describes the tasks covered in this section.

How to Configure SEAM NFS Servers

This procedure requires that the master KDC has been configured. To fully test the process you need several clients. The following configuration parameters are used:

realm name = ACME.COM




DNS domain name = acme.com




NFS server = denver.acme.com




admin principle = kws/admin

1. Prerequisites for configuring a SEAM NFS server.

   The SEAM client software must be installed.

2. (Optional) Install NTP client or other clock synchronization mechanism.

   See "Synchronizing Clocks Between KDCs and SEAM Clients" for information about NTP.

3. Add new principals.

   Using the administration tool provided with your KDC add new principals for the NFS server.

   1. Create the server's NFS service principal.

      Create a principal named: nfs/denver.acme.com.

   2. (Optional) Create a root principal for the NFS server.

      Create a principal named: root/denver.acme.com.

   3. Add the server's NFS service principal to the server's keytab.

      Make sure that the nfs/denver.acme.com principal is included in the keytab file.

4. Create the gsscred table.

   See "How to Create a Credential Table" for more information.

5. Share the NFS file system using Kerberos security modes.

   See "How to Set Up a Secure NFS Environment With Multiple Kerberos Security Modes" for more information.

6. On each client, authenticate both the user and root principals.

How to Change the Back-end Mechanism for the gsscred Table

1. Become superuser on the NFS server.

2. Edit /etc/gss/gsscred.conf and change the mechanism.

   One of the following back-end mechanisms can be used: files, xfn_files, xfn_nis, xfn_nisplus, or xfn. The advantages of each of these mechanisms is covered in "Using the gsscred Table".

How to Create a Credential Table

The gsscred credential table is used by an NFS server to map SEAM principals to a UID. In order for NFS clients to be able to mount file systems from an NFS server using Kerberos authentication, this table must be created or made available.

1. Become superuser on the appropriate server.

   Which server you run this command from and under what ID you run the command depends on the back-end mechanism that has been selected to support the gsscred table. For all mechanisms except xfn_nisplus, you must become root.

   If Your Back-end Mechanism Is ...	Then ....
   files	Run on the NFS server.
   xfn	Select host based on the default xfn file setting.
   xfn_files	Run on the NFS server.
   xfn_nis	Run on the NIS master.
   xfn_nisplus	Run anywhere as long as the permissions to change the NIS+ data are in place.

2. (Optional) If /var/fn does not exist and you want to use one of the xfn options, create an initial XFN database.

   # fnselect files # fncreate -t org -o org//

3. Create the credential table using gsscred.

   The command gathers information from all of the sources listed with the passwd entry in /etc/nsswitch.conf. You might need to temporarily remove the files entry, if you do not want the local password entries included in the credential table. See the gsscred(1M) man page for more information.

   # gsscred -m kerberos_v5 -a

How to Add a Single Entry to the Credential Table

This procedure requires that the gsscred table has already been installed on the NFS server.

1. Become superuser on a NFS server.

2. Add an entry to the table using gsscred.

   # gsscred -m [mech] -n [name] -u [uid] -a

   mech	The security mechanism to be used.
   name	The principal name for the user, as defined in the KDC.
   uid	The UID for the user, as defined in the password database.
   -a	Adds the UID to principal name mapping.

Example--Changing a Single Entry to the Credential Table

The following example adds an entry for the user named sandy, which is mapped to UID 3736. The UID is pulled from the password file, if it is not included on the command line.

# gsscred -m kerberos_v5 -n sandy -u 3736 -a

How to Set Up a Secure NFS Environment With Multiple Kerberos Security Modes

1. Become superuser on the NFS server.

2. Edit the /etc/dfs/dfstab file and add the sec= option with the required security modes to the appropriate entries.

   # share -F nfs -o sec=mode filesystem

   mode	The security modes to be used when sharing. When using multiple security modes, the first mode in the list is used as the default by autofs.
   filesystem	The path to the file system to be shared.

   All clients attempting to access files from the named file system require Kerberos authentication. To complete accessing files, both the user principal and the root principal on the NFS client should be authenticated.

3. Check to be sure the NFS service is running on the server.

   If this is the first share command or set of share commands that you have initiated, it is likely that the NFS daemons are not running. The following set of commands kill the daemons and restart them.

   # /etc/init.d/nfs.server stop # /etc/init.d/nfs.server start

4. Optional: If autofs is being used, edit the auto_master data to select a security mode other than the default.

   You need not follow this procedure if you are not using autofs to access the file system or if the default selection for the security mode is acceptable.

   /home auto_home -nosuid,sec=krbi

5. Optional: Manually issue the mount command to access the file system using a non-default mode.

   Alternatively, you could use the mount command to specify the security mode, but this does not take advantage of the automounter:

   # mount -F nfs -o sec=krb5p /export/home

Example--Sharing a File System With One Kerberos Security Mode

This example will require Kerberos authentication before files can be accessed.

# share -F nfs -o sec=krb5 /export/home

Example--Sharing a File System With Multiple Kerberos Security Modes

In this example, all three Kerberos security modes have been selected. If no security mode is specified when a mount request is made, the first mode listed is used on all NFS V3 clients (in this case, krb5). Additional information can be found in "Changes to the share Command".

# share -F nfs -o sec=krb5:krb5i:krb5p /export/home

Synchronizing Clocks Between KDCs and SEAM Clients

All hosts participating in the Kerberos authentication system must have their internal clocks synchronized within a specified maximum amount of time (known as clock skew), which provides another Kerberos security check. If the clock skew is exceeded between any of the participating hosts, client requests will be rejected.

The clock skew also determines how long application servers must keep track of all Kerberos protocol messages, in order to recognize and reject replayed requests. So, the longer the clock skew value, the more information that application servers have to collect.

The default value for the maximum clock skew is 300 seconds (five minutes), which you can change in the libdefaults section of the krb5.conf file.

For security reasons, do not increase the clock skew beyond 300 seconds.

Since it is important to maintain synchronized clocks between the KDCs and SEAM clients, it is recommended that you use the Network Time Protocol (NTP) software to do this. The NTP public domain software from the University of Delaware is included in the Solaris software starting with the Solaris 2.6 release.

Another way to synchronize clocks is to use the rdate command with cron jobs, which can be a less involved process than using NTP. However, this section will continue to focus on using NTP. And, if you use the network to synchronize the clocks, the clock synchronization protocol must itself be secure.

NTP enables you to manage precise time and network clock synchronization in a network environment. NTP is basically a server/client implementation. You pick one system to be the master clock (NTP server), and then you set up all your other systems to synchronize their clocks with the master clock (NTP clients). This is done through the xntpd daemon, which sets and maintains a UNIX system time-of-day in agreement with Internet standard time servers. The figure below shows an example of server/client NTP implementation.

Figure 22-1 Synchronizing Clocks Using NTP

Ensuring that the KDCs and SEAM clients maintain synchronized clocks involves the following:

1. Set up an NTP server on your network (this can be any system except the master KDC). See "How to Set Up an NTP Server".

2. As you configure the KDCs and SEAM clients on the network, set them up to be NTP clients of the NTP server. See "How to Set Up an NTP Client".

SEAM Client Error Messages

Refer to "SEAM Error Messages and Troubleshooting" in Sun Enterprise Authentication Mechanism Guide for a complete list of SEAM error messages.