Chapter 15 Configuring SEAM (Tasks)

This chapter provides configuration and installation procedures network application servers.

• Configuring KDC Servers

• Configuring Cross-Realm Authentication

• Configuring SEAM NFS Servers

• Configuring SEAM Clients

• Synchronizing Clocks between KDCs and SEAM Clients

• Swapping a Master KDC and a Slave KDC

• Administering the Kerberos Database

• Increasing Security

Configuring SEAM (Task Map)

Parts of the configuration process depend on other parts and must be done in a specific order. These procedures often establish services that are required to use SEAM. Other procedures are not dependent on any order, and can be done when appropriate. The following task map shows a suggested order for a SEAM installation.

Once the required steps have been completed, the following procedures can be used when required.

Configuring KDC Servers

After you install the SEAM software, you must configure the KDC servers. Configuring a master KDC and at least one slave KDC provides the service that issues credentials. These credentials are the basis for SEAM, so the KDCs must be installed before you attempt other tasks.

The most significant difference between a master KDC and a slave KDC is that only the master KDC can handle database administration requests. For instance, changing a password or adding a new principal must be done on the master KDC. These changes can then be propagated to the slave KDCs. Both the slave KDC and master KDC generate credentials. This feature provides redundancy in case the master KDC cannot respond.

How to Configure a Master KDC

In this procedure, the following configuration parameters are used:

• Realm name = EXAMPLE.COM

• DNS domain name = example.com

• Master KDC = kdc1.example.com

• Slave KDC = kdc2.example.com

• admin principal = kws/admin

• Online help URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956

  ---

  Note –

  Adjust the URL to point to the “SEAM Administration Tool” section, as described in Online Help URL.

  ---

1. Complete the prerequisites for configuring a master KDC.

   This procedure requires that DNS must be running. For specific naming instructions if this master is to be swappable, see Swapping a Master KDC and a Slave KDC.

2. Become superuser on the master KDC.

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

   You need to change the realm names and the names of the servers. See the krb5.conf(4) man page for a full description of this file.

   kdc1 # cat /etc/krb5/krb5.conf [libdefaults] default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kdc1.example.com kdc = kdc2.example.com admin_server = kdc1.example.com } [domain_realm] .example.com = EXAMPLE.COM # # if the domain name and realm name are equivalent, # this entry is not needed # [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log [appdefaults] gkadmin = { help_url = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956 }

   In this example, the lines for domain_realm, kdc, admin_server, and all domain_realm entries were changed. In addition, the line that defines the help_url was edited.

4. Edit the KDC configuration file (kdc.conf).

   You need to change the realm name. See the kdc.conf(4) man page for a full description of this file.

   kdc1 # cat /etc/krb5/kdc.conf [kdcdefaults] kdc_ports = 88,750 [realms] EXAMPLE.COM= { profile = /etc/krb5/krb5.conf database_name = /var/krb5/principal admin_keytab = /etc/krb5/kadm5.keytab acl_file = /etc/krb5/kadm5.acl kadmind_port = 749 max_life = 8h 0m 0s max_renewable_life = 7d 0h 0m 0s }

   In this example, the realm name definition in the realms section was changed.

5. Create the KDC database by using the kdb5_util command.

   The kdb5_util command creates the KDC database. Also, when used with the -s option, this command creates a stash file that is used to authenticate the KDC to itself before the kadmind and krb5kdc daemons are started.

   kdc1 # /usr/sbin/kdb5_util create -r EXAMPLE.COM -s Initializing database '/var/krb5/principal' for realm 'EXAMPLE.COM' master key name 'K/M@EXAMPLE.COM' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: <type the key> Re-enter KDC database master key to verify: <type it again>

   The -r option followed by the realm name is not required if the realm name is equivalent to the domain name in the server's name space.

6. Edit the Kerberos access control list file (kadm5.acl).

   Once populated, the /etc/krb5/kadm5.acl file should contain all principal names that are allowed to administer the KDC. The first entry that is added might look similar to the following:

   kws/admin@EXAMPLE.COM *

   This entry gives the kws/admin principal in the EXAMPLE.COM realm the ability to modify principals or policies in the KDC. The default installation includes an asterisk (*) to match all admin principals. This default could be a security risk, so it is more secure to include a list of all of the admin principals. See the kadm5.acl(4) man page for more information.

7. Start the kadmin.local command.

   The next sub-steps create principals that are used by SEAM.

   kdc1 # /usr/sbin/kadmin.local kadmin.local:

   1. Add administration principals to the database.

      You can add as many admin principals as you need. You must add at least one admin principal to complete the KDC configuration process. For this example, a kws/admin principal is added. You can substitute an appropriate principal name instead of “kws.”

      kadmin.local: addprinc kws/admin Enter password for principal kws/admin@EXAMPLE.COM: <type the password> Re-enter password for principal kws/admin@EXAMPLE.COM: <type it again> Principal "kws/admin@EXAMPLE.COM" created. kadmin.local:

   2. Create a keytab file for the kadmind service.

      This command sequence creates a special keytab file with principal entries for kadmin and changepw. These principals are needed for the kadmind service. Note that when the principal instance is a host name, the FQDN must be entered in lowercase letters, regardless of the case of the domainname in the /etc/resolv.conf file.

      kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc1.example.com Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab. kadmin.local: ktadd -k /etc/krb5/kadm5.keytab changepw/kdc1.example.com Entry for principal changepw/kdc1.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab. kadmin.local:

   3. Quit kadmin.local.

      You have added all of the required principals for the next steps.

      kadmin.local: quit

8. Start the Kerberos daemons.

   kdc1 # /etc/init.d/kdc start kdc1 # /etc/init.d/kdc.master start

9. Start kadmin.

   At this point, you can add principals by using the SEAM Administration Tool. To do so, you must log on with one of the admin principal names that you created earlier in this procedure. However, the following command-line example is shown for simplicity.

   kdc1 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin:

   1. Create the master KDC host principal.

      The host principal is used by Kerberized applications (such as klist and kprop) . Note that when the principal instance is a host name, the FQDN must be entered in lowercase letters, regardless of the case of the domainname in the /etc/resolv.conf file.

      kadmin: addprinc -randkey host/kdc1.example.com Principal "host/kdc1.example.com@EXAMPLE.COM" created. kadmin:

   2. (Optional) Create the master KDC root principal.

      This principal is used for authenticated NFS-mounting. So, the principal might not be necessary on a master KDC. Note that when the principal instance is a host name, the FQDN must be entered in lowercase letters, regardless of the case of the domainname in the /etc/resolv.conf file.

      kadmin: addprinc root/kdc1.example.com Enter password for principal root/kdc1.example.com@EXAMPLE.COM: <type the password> Re-enter password for principal root/kdc1.example.com@EXAMPLE.COM: <type it again> Principal "root/kdc1.example.com@EXAMPLE.COM" created. kadmin:

   3. Add the master KDC's host principal to the master KDC's keytab file.

      Adding the host principal to the keytab file allows this principal to be used automatically.

      kadmin: ktadd host/kdc1.example.com kadmin: Entry for principal host/kdc1.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab kadmin:

   4. Quit kadmin.

      kadmin: quit

10. Add an entry for each KDC into the propagation configuration file (kpropd.acl).

    See the kprop(1M) man page for a full description of this file.

    kdc1 # cat /etc/krb5/kpropd.acl host/kdc1.example.com@EXAMPLE.COM host/kdc2.example.com@EXAMPLE.COM

11. (Optional) Synchronize the master KDCs clock by using NTP or another clock synchronization mechanism.

    It is not required to install and use the Network Time Protocol (NTP). However, every clock must be within the default time that is defined in the libdefaults section of the krb5.conf file in order for authentication to succeed. See Synchronizing Clocks between KDCs and SEAM Clients for information about NTP.

How to Configure a Slave KDC

In this procedure, a new slave KDC named kdc3 is configured. This procedure uses the following configuration parameters:

• Realm name = EXAMPLE.COM

• DNS domain name = example.com

• Master KDC = kdc1.example.com

• Slave KDC = kdc2.example.com and kdc3.example.com

• admin principal = kws/admin

• Online help URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956

  ---

  Note –

  Adjust the URL to point to the “SEAM Administration Tool” section, as described in the Online Help URL.

  ---

1. Complete the prerequisites for configuring a slave KDC.

   The master KDC must be configured. For specific instructions if this slave is to be swappable, see Swapping a Master KDC and a Slave KDC.

2. On the master KDC, become superuser.

3. On the master KDC, start kadmin.

   You must log on with one of the admin principal names that you created when you configure the master KDC.

   kdc1 # /usr/sbin/kadmin -p kws/admin Enter password: <Enter kws/admin password> kadmin:

   1. On the master KDC, add slave host principals to the database, if not already done.

      In order for the slave to function, it must have a host principal. Note that when the principal instance is a host name, the FQDN must be entered in lowercase letters, regardless of the case of the domainname in the /etc/resolv.conf file.

      kadmin: addprinc -randkey host/kdc3.example.com Principal "host/kdc3@EXAMPLE.COM" created. kadmin:

   2. (Optional) On the master KDC, create the slave KDC root principal.

      This principal is only needed if the slave will be NFS-mounting an authenticated file system. Note that when the principal instance is a host name, the FQDN must be entered in lowercase letters, regardless of the case of the domainname in the /etc/resolv.conf file.

      kadmin: addprinc root/kdc3.example.com Enter password for principal root/kdc3.example.com@EXAMPLE.COM: <type the password> Re-enter password for principal root/kdc3.example.com@EXAMPLE.COM: <type it again> Principal "root/kdc3.example.com@EXAMPLE.COM" created. kadmin:

   3. Quit kadmin.

      kadmin: quit

4. On the master KDC, edit the Kerberos configuration file (krb5.conf).

   You need to add an entry for each slave. See the krb5.conf(4) man page for a full description of this file.

   kdc1 # cat /etc/krb5/krb5.conf [libdefaults] default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kdc1.example.com kdc = kdc2.example.com kdc = kdc3.example.com admin_server = kdc1.example.com } [domain_realm] .example.com = EXAMPLE.COM # # if the domain name and realm name are equivalent, # this entry is not needed # [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log [appdefaults] gkadmin = { help_url = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956

5. On the master KDC, add an entry for each slave KDC into the database propagation configuration file (kpropd.acl).

   See the kprop(1M) man page for a full description of this file.

   kdc1 # cat /etc/krb5/kpropd.acl host/kdc1.example.com@EXAMPLE.COM host/kdc2.example.com@EXAMPLE.COM host/kdc3.example.com@EXAMPLE.COM

6. On all slave KDCs, copy the KDC administration files from the master KDC server.

   This step needs to be followed on all slave KDCs, since the master KDC server has updated information that each KDC server needs. You can use ftp or a similar transfer mechanism to grab copies of the following files from the master KDC:

   • /etc/krb5/krb5.conf

   • /etc/krb5/kdc.conf

   • /etc/krb5/kpropd.acl

7. On the new slave, add the slave's host principal to the slave's keytab file by using kadmin.

   You must log on with one of the admin principal names that you created when you configure the master KDC. This entry allows kprop and other Kerberized applications to function. Note that when the principal instance is a host name, the FQDN must be entered in lowercase letters, regardless of the case of the domainname in the /etc/resolv.conf file.

   kdc3 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: ktadd host/kdc3.example.com kadmin: Entry for principal host/kdc3.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab kadmin: quit

8. On the master KDC, add slave KDC names to the cron job, which automatically runs the backups, by running crontab -e.

   Add the name of each slave KDC server at the end of the kprop_script line.

   10 3 * * * /usr/lib/krb5/kprop_script kdc2.example.com kdc3.example.com

   You might also want to change the time of the backups. This configuration starts the backup process every day at 3:10 AM.

9. On the master KDC, back up and propagate the database by using kprop_script.

   If a backup copy of the database is already available, it is not necessary to complete another backup. See How to Manually Propagate the Kerberos Database to the Slave KDCs for further instructions.

   kdc1 # /usr/lib/krb5/kprop_script kdc3.example.com Database propagation to kdc3.example.com: SUCCEEDED

10. On the new slave, create a stash file by using kdb5_util.

    kdc3 # /usr/sbin/kdb5_util stash kdb5_util: Cannot find/read stored master key while reading master key kdb5_util: Warning: proceeding without master key Enter KDC database master key: <type the key>

11. (Optional) On the new slave KDC, synchronize the master KDCs clock by using NTP or another clock synchronization mechanism.

    It is not required to install and use the Network Time Protocol (NTP). However, every clock must be within the default time that is defined in the libdefaults section of the krb5.conf file in order for authentication to succeed. See Synchronizing Clocks between KDCs and SEAM Clients for information about NTP.

12. On the new slave, start the KDC daemon (krb5kdc).

    kdc3 # /etc/init.d/kdc start

Configuring Cross-Realm Authentication

You have several ways of linking realms together so that users in one realm can be authenticated in another realm. Normally, this cross-realm authentication is accomplished by establishing a secret key that is shared between the two realms. The relationship of the realms can be either hierarchal or directional (see Realm Hierarchy).

How to Establish Hierarchical Cross-Realm Authentication

The example in this procedure uses two realms, ENG.EAST.EXAMPLE.COM and EAST.EXAMPLE.COM. Cross-realm authentication will be established in both directions. This procedure must be completed on the master KDC in both realms.

1. Complete the prerequisites for establishing hierarchical cross-realm authentication.

   The master KDC for each realm must be configured. To fully test the authentication process, several clients or slave KDCs must be installed.

2. Become superuser on the first master KDC.

3. Create ticket-granting ticket service principals for the two realms.

   You must log on with one of the admin principal names that was created when you configured the master KDC.

   # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: addprinc krbtgt/ENG.EAST.EXAMPLE.COM@EAST.EXAMPLE.COM Enter password for principal krgtgt/ENG.EAST.EXAMPLE.COM@EAST.EXAMPLE.COM: <type the password> kadmin: addprinc krbtgt/EAST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM Enter password for principal krgtgt/EAST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM: <type the password> kadmin: quit

   ---

   Note –

   The password that is entered for each service principal must be identical in both KDCs. Thus, the password for the service principal krbtgt/ENG.EAST.EXAMPLE.COM@EAST.EXAMPLE.COM must be the same in both realms.

   ---

4. Add entries to the Kerberos configuration file to define domain names for every realm (krb5.conf).

   # cat /etc/krb5/krb5.conf [libdefaults] . . [domain_realm] .eng.east.example.com = ENG.EAST.EXAMPLE.COM .east.example.com = EAST.EXAMPLE.COM

   In this example, domain names for the ENG.EAST.EXAMPLE.COM and EAST.EXAMPLE.COM realms are defined. It is important to include the subdomain first, since the file is searched top down.

5. Copy the Kerberos configuration file to all clients in this realm.

   In order for cross-realm authentication to work, all systems (including slave KDCs and other servers) must have the new version of the Kerberos configuration file (/etc/krb5/krb5.conf) installed.

6. Repeat these steps in the second realm.

How to Establish Direct Cross-Realm Authentication

The example in this procedure uses two realms: ENG.EAST.EXAMPLE.COM and SALES.WEST.EXAMPLE.COM. Cross-realm authentication will be established in both directions. This procedure must be completed on the master KDC in both realms.

1. Complete the prerequisites for establishing direct cross-realm authentication.

   The master KDC for each realm must be configured. To fully test the authentication process, several clients or slave KDCs must be installed.

2. Become superuser on one of the master KDC servers.

3. Create ticket-granting ticket service principals for the two realms.

   You must log on with one of the admin principal names that was created when you configured the master KDC.

   # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: addprinc krbtgt/ENG.EAST.EXAMPLE.COM@SALES.WEST.EXAMPLE.COM Enter password for principal krgtgt/ENG.EAST.EXAMPLE.COM@SALES.WEST.EXAMPLE.COM: <type the password> kadmin: addprinc krbtgt/SALES.WEST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM Enter password for principal krgtgt/SALES.WEST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM: <type the password> kadmin: quit

   ---

   Note –

   The password that is entered for each service principal must be identical in both KDCs. Thus, the password for the service principal krbtgt/ENG.EAST.EXAMPLE.COM@SALES.WEST.EXAMPLE.COM must be the same in both realms.

   ---

4. Add entries in the Kerberos configuration file to define the direct path to the remote realm (krb5.conf).

   This example shows the clients in the ENG.EAST.EXAMPLE.COM realm. You would need to swap the realm names to get the appropriate definitions in the SALES.WEST.EXAMPLE.COM realm.

   # cat /etc/krb5/krb5.conf [libdefaults] . . [capaths] ENG.EAST.EXAMPLE.COM = { SALES.WEST.EXAMPLE.COM = . } SALES.WEST.EXAMPLE.COM = { ENG.EAST.EXAMPLE.COM = . }

5. Copy the Kerberos configuration file to all clients in the current realm.

   In order for cross-realm authentication to work, all systems (including slave KDCs and other servers) must have the new version of the Kerberos configuration file (krb5.conf) installed.

6. Repeat these steps for the second realm.

Configuring SEAM NFS Servers

NFS services use UNIX user IDs (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 in this section focus on the tasks that are necessary to configure a SEAM NFS server, to administer the credential table, and to initiate Kerberos security modes for NFS-mounted file systems. The following task map describes the tasks that are covered in this section.

How to Configure SEAM NFS Servers

In this procedure, the following configuration parameters are used:

• Realm name = EXAMPLE.COM

• DNS domain name = example.com

• NFS server = denver.example.com

• admin principal = kws/admin

1. Complete the prerequisites for configuring a SEAM NFS server.

   The master KDC must be configured. To fully test the process, you need several clients.

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

   It is not required to install and use the Network Time Protocol (NTP). However, every clock must be within the default time that is defined in the libdefaults section of the krb5.conf file in order for authentication to succeed. See Synchronizing Clocks between KDCs and SEAM Clients for information about NTP.

3. Start kadmin.

   You can use the SEAM Administration Tool to add a principal, as explained in How to Create a New Principal. To do so, you must log on with one of the admin principal names that you created when you configured the master KDC. However, the following example shows how to add the required principals by using the command line.

   denver # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin:

   1. Create the server's NFS service principal.

      Note that when the principal instance is a host name, the FQDN must be entered in lowercase letters, regardless of the case of the domainname in the /etc/resolv.conf file.

      kadmin: addprinc -randkey nfs/denver.example.com Principal "nfs/denver.example.com" created. kadmin:

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

      kadmin: addprinc root/denver.example.com Enter password for principal root/denver.example.com@EXAMPLE.COM: <type the password> Re-enter password for principal root/denver.example.com@EXAMPLE.COM: <type it again> Principal "root/denver.example.com@EXAMPLE.COM" created. kadmin:

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

      kadmin: ktadd nfs/denver.example.com kadmin: Entry for principal nfs/denver.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab kadmin:

   4. Quit kadmin.

      kadmin: quit

4. Create the gsscred table.

   See How to Create a Credential Table for more information.

5. Share the NFS file system with 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 principal and the root principal.

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 mount file systems from an NFS server with Kerberos authentication, this table must be created or made available.

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

   Change the mechanism to files.

2. Create the credential table by using gsscred.

   # gsscred -m kerberos_v5 -a

   The gsscred command gathers information from all sources that are listed with the passwd entry in the /etc/nsswitch.conf file. 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.

How to Add a Single Entry to the Credential Table

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

1. Become superuser on a NFS server.

2. Add an entry to the table by using gsscred.

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

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

Example—Adding a Single Entry to the Credential Table

In the following example, an entry is added 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. Verify that there is a NFS service principal in the keytab file.

   The klist command reports if there is a keytab file and displays the principals. If the results show that there is no keytab file or that there is no NFS service principal, you need to verify the completion of all of the steps in How to Configure SEAM NFS Servers.

   # klist -k Keytab name: FILE:/etc/krb5/krb5.keytab KVNO Principal ---- --------------------------------------------------------- 3 nfs/denver.example.com@EXAMPLE.COM

3. Enable Kerberos security modes in the /etc/nfssec.conf file.

   Edit the /etc/nfssec.conf file and remove the “#” from in front of the Kerberos security modes.

   # 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 krb5p 390005 kerberos_v5 default privacy # RPCSEC_GSS

4. 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 file-system

   mode	Specifies 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 the automounter.
   file-system	Defines the path to the file system to be shared.

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

5. Make sure that the NFS service is running on the server.

   If this command 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 commands kill the daemons and restart them.

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

6. (Optional) If the automounter is being used, edit the auto_master database to select a security mode other than the default.

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

   file-system auto_home -nosuid,sec=mode

7. (Optional) Manually issue the mount command to access the file system by using a non-default mode.

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

   # mount -F nfs -o sec=mode file-system

Example—Sharing a File System With One Kerberos Security Mode

In this example, the dfstab file line means that Kerberos authentication must succeed before any files can be accessed through the NFS service.

# grep krb /etc/dfs/dfstab
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 that is listed is used on all NFS V3 clients (in this case, krb5). See the nfssec.conf(4) man page for more information.

# grep krb /etc/dfs/dfstab
share -F nfs -o sec=krb5:krb5i:krb5p /export/home

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.

How to Configure a SEAM Client

In this procedure, the following configuration parameters are used:

• Realm name = EXAMPLE.COM

• DNS domain name = example.com

• Master KDC = kdc1.example.com

• Slave KDC = kdc2.example.com

• Client = client.example.com

• admin principal = kws/admin

• User principal = mre

• Online help URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956

  ---

  Note –

  Adjust the URL to point to the “SEAM Administration Tool” section, as described in the Online Help URL.

  ---

1. Become superuser.

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

   To change the file from the SEAM default version, you need to change the realm names and the names of the servers. You also need to identify the path to the help files for gkadmin.

   kdc1 # cat /etc/krb5/krb5.conf [libdefaults] default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kdc1.example.com kdc = kdc2.example.com admin_server = kdc1.example.com } [domain_realm] .example.com = EXAMPLE.COM # # if the domain name and realm name are equivalent, # this entry is not needed # [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log [appdefaults] gkadmin = { help_url = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956

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

   It is not required to install and use the Network Time Protocol (NTP). However, every clock must be within the default time that is defined in the libdefaults section of the krb5.conf file in order for authentication to succeed. See Synchronizing Clocks between KDCs and SEAM Clients for information about NTP.

4. (Optional) Create a user principal if a user principal does not already exist.

   You need to create a user principal only if the user associated with this host does not have a principal assigned already. See How to Create a New Principal for instructions on using the SEAM Administration Tool. The following is a command-line example.

   client1 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: addprinc mre Enter password for principal mre@EXAMPLE.COM: <type the password> Re-enter password for principal mre@EXAMPLE.COM: <type it again> kadmin:

5. Create a root principal.

   Note that when the principal instance is a host name, the FQDN must be entered in lowercase letters, regardless of the case of the domainname in the /etc/resolv.conf file.

   kadmin: addprinc root/client1.example.com Enter password for principal root/client1.example.com@EXAMPLE.COM: <type the password> Re-enter password for principal root/client1.example.com@EXAMPLE.COM: <type it again> kadmin: quit

6. (Optional) To use Kerberos with NFS, enable Kerberos security modes in the /etc/nfssec.conf file.

   Edit the /etc/nfssec.conf file and remove the “#” from in front of the Kerberos security modes.

   # 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 krb5p 390005 kerberos_v5 default privacy # RPCSEC_GSS

7. (Optional) If you want a user on the SEAM client to automatically mount Kerberized NFS file systems that use Kerberos authentication, you must authenticate the root user.

   This process is done most securely by using the kinit command. However, users will need to use kinit as root every time they need to mount a file system that is secured by Kerberos. You can choose to use a keytab file instead. For detailed information about the keytab file requirement, see Setting Up Root Authentication to Mount NFS File Systems.

   client1 # /usr/bin/kinit root/client1.example.com Password for root/client1.example.com@EXAMPLE.COM: <Type password>

   To use the keytab file option, add the root principal to the client's keytab by using kadmin:

   client1 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: ktadd root/client1.example.com kadmin: Entry for principal root/client.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab kadmin: quit

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

   See the warn.conf(4) man page for more information.

Example—Setting Up a SEAM Client Using a Non-SEAM KDC

It is possible to set up a SEAM client to work with a non-SEAM KDC. In this case, a line must be included in the /etc/krb5/krb5.conf file in the realms section. This line changes the protocol that is used when the client is communicating with the Kerberos password-changing server. The format of this line follows.

[realms]
                EXAMPLE.COM = {
                kdc = kdc1.example.com
                kdc = kdc2.example.com
                admin_server = kdc1.example.com
                kpasswd_protocol = SET_CHANGE
        }

Setting Up Root Authentication to Mount NFS File Systems

If users want to access a non-Kerberized NFS file system, either the NFS file system can be mounted as root, or the file system can be accessed automatically through the automounter whenever users access it (without requiring root permissions).

Mounting a Kerberized NFS file system is very much the same, but it does incur an additional obstacle. To mount a Kerberized NFS file system, users must use the kinit command as root to obtain credentials for the client's root principal, because a client's root principal is typically not in the client's keytab. This step is required even when the automounter is set up. This step also forces all users to know their system's root password and the root principal's password.

To bypass this step, you can add a client's root principal to the client's keytab file, which automatically provides credentials for root. Although this solution enables users to mount NFS file systems without running the kinit command and enhances ease-of-use, it is a security risk. For example, if someone gains access to a system with the root principal in its keytab, this person can obtain credentials for root. So make sure that you take the appropriate security precautions. See Administering Keytab Files for more information.

Synchronizing Clocks between KDCs and SEAM Clients

All hosts that participate in the Kerberos authentication system must have their internal clocks synchronized within a specified maximum amount of time (known as clock skew). This requirement provides another Kerberos security check. If the clock skew is exceeded between any of the participating hosts, client requests are 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). You can change this default 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, you should use the Network Time Protocol (NTP) software to synchronize them. 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 and cron jobs, a process that can be less involved 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 or network clock synchronization, or both, in a network environment. NTP is basically a server/client implementation. You pick one system to be the master clock (the NTP server). Then, you set up all your other systems (the NTP clients) to synchronize their clocks with the master clock.

To synchronize the clocks, NTP uses the xntpd daemon, which sets and maintains a UNIX system time-of-day in agreement with Internet standard time servers. The following shows an example of this server/client NTP implementation.

Figure 15–1 Synchronizing Clocks by Using NTP

To ensure that the KDCs and SEAM clients maintain synchronized clocks, implement the following steps:

1. Set up an NTP server on your network (this server can be any system, except the master KDC). See “Managing Network Time Protocol (Tasks)” in System Administration Guide: Resource Management and Network Services to find the NTP server task.

2. As you configure the KDCs and SEAM clients on the network, set them up to be NTP clients of the NTP server. See “Managing Network Time Protocol (Tasks)” in System Administration Guide: Resource Management and Network Services to find the NTP client task.

Swapping a Master KDC and a Slave KDC

You should use the procedures in this section to make the swap of a master KDC with a slave KDC easier. You should swap the master KDC with a slave KDC only if the master KDC server fails for some reason, or if the master KDC needs to be re-installed (for example, because new hardware is installed).

How to Configure a Swappable Slave KDC

Perform this procedure on the slave KDC server that you want to have available to become the master KDC.

1. Use alias names for the master KDC and the swappable slave KDC during the KDC installation.

   When you define the host names for the KDCs, make sure that each system has an alias included in DNS. Also, use the alias names when you define the hosts in the /etc/krb5/krb5.conf file.

2. Follow the steps to install a slave KDC.

   Prior to any swap, this server should function as any other slave KDC in the realm. See How to Configure a Slave KDC for instructions.

3. Move the master KDC commands.

   To prevent the master KDC commands from being run from this slave KDC, move the kprop, kadmind and kadmin.local commands to a reserved place.

   kdc4 # mv /usr/lib/krb5/kprop /usr/lib/krb5/kprop.save kdc4 # mv /usr/lib/krb5/kadmind /usr/lib/krb5/kadmind.save kdc4 # mv /usr/sbin/kadmin.local /usr/sbin/kadmin.local.save

4. Comment out the kprop line in the root crontab file.

   This step prevents the slave KDC from propagating its copy of the KDC database.

   kdc4 # crontab -e #ident "@(#)root 1.20 01/11/06 SMI" # # The root crontab should be used to perform accounting data collection. # # The rtc command is run to adjust the real time clock if and when # daylight savings time changes. # 10 3 * * * /usr/sbin/logadm 15 3 * * 0 /usr/lib/fs/nfs/nfsfind 1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1 30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean #10 3 * * * /usr/lib/krb5kprop_script kdc1.example.sun.com #SUNWkr5ma

How to Swap a Master KDC and a Slave KDC

This procedure requires that the slave KDC server has been set up as a swappable slave (see How to Configure a Swappable Slave KDC). In this procedure, the master KDC server that is being swapped out is named kdc1. The slave KDC that will become the new master KDC is named kdc4.

1. On the old master KDC, kill the kadmind process.

   kdc1 # /etc/init.d/kdc.master stop

   When you kill the kadmind process, you prevent any changes from being made to the KDC database.

2. On the old master KDC, comment out the kprop line in the root crontab file.

   kdc1 # crontab -e #ident "@(#)root 1.20 01/11/06 SMI" # # The root crontab should be used to perform accounting data collection. # # The rtc command is run to adjust the real time clock if and when # daylight savings time changes. # 10 3 * * * /usr/sbin/logadm 15 3 * * 0 /usr/lib/fs/nfs/nfsfind 1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1 30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean #10 3 * * * /usr/lib/krb5/kprop_script kdc2.example.sun.com #SUNWkr5ma

   This step prevents the old master from propagating its copy of the KDC database.

3. On the old master KDC, run kprop_script to back up and propagate the database.

   kdc1 # /usr/lib/krb5/kprop_script kdc4.example.com Database propagation to kdc4.example.com: SUCCEEDED

4. On the old master KDC, move the master KDC commands.

   To prevent the master KDC commands from being run, move the kprop, kadmind and kadmin.local commands to a reserved place.

   kdc4 # mv /usr/lib/krb5/kprop /usr/lib/krb5/kprop.save kdc4 # mv /usr/lib/krb5/kadmind /usr/lib/krb5/kadmind.save kdc4 # mv /usr/sbin/kadmin.local /usr/sbin/kadmin.local.save kdc4 # mv /etc/krb5/kadm5.acl /etc/krb5/kadm5.acl.save

5. On the DNS server, change the alias names for the master KDC.

   To change the servers, edit the example.com zone file and change the entry for masterkdc.

   masterkdc IN CNAME kdc4

6. On the DNS server, restart the Internet domain name server.

   Run the following command on both servers to get the new alias information:

   # pkill -1 in.named

7. On the new master KDC, move the master KDC commands.

   kdc4 # mv /usr/lib/krb5/kprop.save /usr/lib/krb5/kprop kdc4 # mv /usr/lib/krb5/kadmind.save /usr/lib/krb5/kadmind kdc4 # mv /usr/sbin/kadmin.local.save /usr/sbin/kadmin.local

8. On the new master KDC, edit the Kerberos access control list file (kadm5.acl).

   Once populated, the /etc/krb5/kadm5.acl file should contain all principal names that are allowed to administer the KDC. The first entry that is added might look similar to the following:

   kws/admin@EXAMPLE.COM *

   This entry gives the kws/admin principal in the EXAMPLE.COM realm the ability to modify principals or policies in the KDC. The default installation includes an asterisk (*) to match all admin principals. This default could be a security risk, so it is more secure to include a list of all of the admin principals. See the kadm5.acl(4) man page for more information.

9. On the new master KDC, create a keytab file for kadmin by using kadmin.local.

   This command sequence creates a special keytab file with principal entries for admin and changepw. These principals are needed for the kadmind service.

   kdc4 # /usr/sbin/kadmin.local kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc4.example.com Entry for principal kadmin/kdc4.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab. kadmin.local: ktadd -k /etc/krb5/kadm5.keytab changepw/kdc4.example.com Entry for principal changepw/kdc4.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab. kadmin.local: quit

10. On the new master KDC, start kadmind.

    kdc4 # /etc/init.d/kdc.master start

11. Enable the kprop line in the root crontab file.

    kdc4 # crontab -e #ident "@(#)root 1.19 98/07/06 SMI" # # The root crontab should be used to perform accounting data collection. # # The rtc command is run to adjust the real time clock if and when # daylight savings time changes. # 10 3 * * * /usr/sbin/logadm 15 3 * * 0 /usr/lib/fs/nfs/nfsfind 1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1 30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean 10 3 * * * /usr/lib/krb5/kprop_script kdc1.example.sun.com #SUNWkr5ma

Administering the Kerberos Database

The Kerberos database is the backbone of Kerberos and must be maintained properly. This section provides some procedures on how to administer the Kerberos database, such as backing up and restoring the database, setting up parallel propagation, and administering the stash file. The steps to initially set up the database are in How to Configure a Master KDC.

Backing Up and Propagating the Kerberos Database

Propagating the Kerberos database from the master KDC to the slave KDCs is one of the most important configuration tasks. If propagation doesn't happen often enough, the master KDC and the slave KDCs will lose synchronization. So, if the master KDC goes down, the slave KDCs will not have the most recent database information. Also, if a slave KDC has been configured as a master KDC for purposes of load balancing, the clients that use that slave KDC as a master KDC will not have the latest information. Therefore, you must make sure that propagation occurs often enough, based on how often you change the Kerberos database.

When you configure the master KDC, you set up the kprop_script command in a cron job to automatically back up the Kerberos database to the /var/krb5/slave_datatrans dump file and propagate it to the slave KDCs. But, as with any file, the Kerberos database can become corrupted. If data corruption occurs on a slave KDC, you might never notice, since the next automatic propagation of the database installs a fresh copy. However, if corruption occurs on the master KDC, the corrupted database is propagated to all of the slave KDCs during the next propagation. And, the corrupted backup overwrites the previous uncorrupted backup file on the master KDC.

Because there is no “safe” backup copy in this scenario, you should also set up a cron job to periodically copy the slave_datatrans dump file to another location or to create another separate backup copy by using the dump command of kdb5_util. Then, if your database becomes corrupted, you can restore the most recent backup on the master KDC by using the load command of kdb5_util.

Another important note: Because the database dump file contains principal keys, you need to protect the file from being accessed by unauthorized users. By default, the database dump file has read and write permissions only as root. To protect against unauthorized access, use only the kprop command to propagate the database dump file, which encrypts the data that is being transferred. Also, kprop propagates the data only to the slave KDCs, which minimizes the chance of accidentally sending the database dump to unauthorized hosts.

If the Kerberos database is updated after it has been propagated and if the database subsequently is corrupted before the next propagation, the KDC slaves will not contain the updates. The updates will be lost. For this reason, if you add significant updates to the Kerberos database before a regularly scheduled propagation, you should manually propagate the database to avoid data loss.

The kpropd.acl File

The kpropd.acl file on a KDC provides a list of host principal names, one per line, that specifies the systems from which the KDC can receive an updated database through propagation. If the master KDC is used to propagate all the slave KDCs, the kpropd.acl file on each slave needs to contain only the host principal name of the master KDC.

However, the SEAM installation and subsequent configuration steps in this book instruct you to add the same kpropd.acl file to the master KDC and the slave KDCs. This file contains all the KDC host principal names. This configuration allows you to propagate from any KDC, in case the propagating KDCs become temporarily unavailable. And, by keeping an identical copy on all KDCs, you make the configuration easy to maintain.

The kprop_script Command

The kprop_script command uses the kprop command to propagate the Kerberos database to other KDCs. If the kprop_script command is run on a slave KDC, it propagates the slave KDC's copy of the Kerberos database to other KDCs. The kprop_script accepts a list of host names for arguments, separated by spaces, which denote the KDCs to propagate.

When the kprop_script is run, it creates a backup of the Kerberos database to the /var/krb5/slave_datatrans file and copies the file to the specified KDCs. The Kerberos database is locked until the propagation is finished.

How to Back Up the Kerberos Database

1. Become superuser on the master KDC.

2. Back up the Kerberos database by using the dump command of the kdb5_util command.

   # /usr/sbin/kdb5_util dump [-verbose] [-d dbname] [filename [principals...]]

   -verbose	Prints the name of each principal and policy that is being backed up.
   dbname	Defines the name of the database to back up. Note that “.db” is appended to whatever database name is specified, and you can specify an absolute path for the file. If the -d option is not specified, the default database name is /var/krb5/principal, which actually becomes /var/krb5/principal.db.
   filename	Defines the file that is used to back up the database. You can specify an absolute path for the file. If you don't specify a file, the database is dumped to standard output.
   principal	Defines a list of one or more principals (separated by a space) to back up. You must use fully-qualified principal names. If you don't specify any principals, the entire database is backed up.

Example—Backing Up the Kerberos Database

In the following example, the Kerberos database is backed up to a file called dumpfile. Because the -verbose option is specified, each principal is printed as it is backed up.

# kdb5_util dump -verbose dumpfile 
kadmin/kdc1.eng.example.com@ENG.EXAMPLE.COM 
krbtgt/eng.example.com@ENG.EXAMPLE.COM 
kadmin/history@ENG.EXAMPLE.COM 
pak/admin@ENG.EXAMPLE.COM 
pak@ENG.EXAMPLE.COM
changepw/kdc1.eng.example.com@ENG.EXAMPLE.COM

In the following example, the pak and pak/admin principals are backed up from the Kerberos database.

# kdb5_util dump -verbose dumpfile pak/admin@ENG.EXAMPLE.COM pak@ENG.EXAMPLE.COM
pak/admin@ENG.EXAMPLE.COM
pak@ENG.EXAMPLE.COM

How to Restore the Kerberos Database

1. Become superuser on the master KDC.

2. Restore the Kerberos database by using the load command of kdb_util.

   # /usr/sbin/kdb5_util load [-verbose] [-d dbname] [-update] [filename]

   -verbose	Prints the name of each principal and policy that is being restored.
   dbname	Defines the name of the database to restore. Note that “.db” is appended to whatever database name is specified, and you can specify an absolute path for the file. If the -d option is not specified, the default database name is /var/krb5/principal, which actually becomes /var/krb5/principal.db.
   -update	Updates the existing database. Otherwise, a new database is created or the existing database is overwritten.
   filename	Defines the file from which to restore the database. You can specify an absolute path for the file.

Example—Restoring the Kerberos Database

In the following example, the database called database1.db is restored into the current directory from the dumpfile file. Since the -update option isn't specified, a new database is created by the restore.

# kdb5_util load -d database1 dumpfile

How to Manually Propagate the Kerberos Database to the Slave KDCs

This procedure shows you how to propagate the Kerberos database by using the kprop command. Use this procedure if you need to synchronize a slave KDC with the master KDC outside the periodic cron job. And, unlike the kprop_script, you can use kprop to propagate just the current database backup without first making a new backup of the Kerberos database.

1. Become superuser on the master KDC.

2. (Optional) Back up the database by using the kdb5_util command.

   # /usr/sbin/kdb5_util dump /var/krb5/slave_datatrans

3. Propagate the database to a slave KDC by using the kprop command.

   # /usr/lib/krb5/kprop -f /var/krb5/slave_datatrans slave_KDC

If you want to back up the database and propagate it to a slave KDC outside the periodic cron job, you can also use the kprop_script command as follows:

# /usr/lib/krb5/kprop_script slave_KDC

Setting Up Parallel Propagation

In most cases, the master KDC is used exclusively to propagate its Kerberos database to the slave KDCs. However, if your site has many slave KDCs, you might consider load-sharing the propagation process, known as parallel propagation.

Parallel propagation allows specific slave KDCs to share the propagation duties with the master KDC. This sharing of duties enables the propagation to be done faster and to lighten the work for the master KDC.

For example, say your site has one master KDC and six slave KDCs (shown in Figure 15–2), where slave-1 through slave-3 consist of one logical grouping and slave-4 through slave-6 consist of another logical grouping. To set up parallel propagation, you could have the master KDC propagate the database to slave-1 and slave-4, and those KDC slaves could in turn propagate the database to the KDC slaves in their group.

Figure 15–2 Example of Parallel Propagation Configuration

How to Set Up Parallel Propagation

The following is not a detailed step-by-step procedure, but a high-level list of configuration steps to enable parallel propagation.

1. On the master KDC, change the kprop_script entry in its cron job to include arguments for only the KDC slaves that will perform the succeeding propagation (propagation slaves).

2. On each propagation slave, add a kprop_script entry to its cron job, which must include arguments for the slaves to propagate. To successfully propagate in parallel, the cron job should be set up to run after the propagation slave is itself propagated with the new Kerberos database.

   ---

   Note –

   How long it will take for a propagation slave to be propagated depends on factors such as network bandwidth and the size of the database.

   ---

3. On each slave KDC, set up the appropriate permissions to be propagated. This step is done by adding the host principal name of its propagating KDC to its kpropd.acl file.

Example—Setting Up Parallel Propagation

Using the example in Figure 15–2, the master KDC's kprop_script entry would look similar to the following:

0 3 * * * /usr/lib/krb5/kprop_script slave-1.example.com slave-4.example.com

The slave-1's kprop_script entry would look similar to the following:

0 4 * * * /usr/lib/krb5/kprop_script slave-2.example.com slave-3.example.com

Note that the propagation on the slave starts an hour after it is propagated by the master.

The kpropd.acl file on the propagation slaves would contain the following entry:

host/master.example.com@EXAMPLE.COM

The kpropd.acl file on the KDC slaves being propagated by slave-1 would contain the following entry:

host/slave-1.example.com@EXAMPLE.COM

Administering the Stash File

The stash file contains the master key for the Kerberos database, which is automatically created when you create a Kerberos database. If the stash file gets corrupted, you can use the stash command of the kdb5_util utility to replace the corrupted file. The only time you should need to remove a stash file is after removing the Kerberos database with the destroy command of kdb5_util. Because the stash file isn't automatically removed with the database, you have to remove it to finish the cleanup.

How to Remove a Stash File

1. Become superuser on the KDC that contains the stash file.

2. Remove the stash file.

   # rm stash-file

   In this example, stash-file is the path to the stash file. By default, the stash file is located at /var/krb5/.k5.realm.

If you need to re-create the stash file, you can use the -f option of the kdb5_util command.

Increasing Security

Follow these steps to increase security on SEAM application servers and on KDC servers.

How to Restrict Access to KDC Servers

Both master KDC servers and slave KDC servers have copies of the KDC database stored locally. Restricting access to these servers so that the databases are secure is important to the overall security of the SEAM installation.

1. Disable remote services in the /etc/inetd.conf file.

   To provide a secure KDC server, all nonessential network services should be disabled by commenting out the entry that starts the service in the /etc/inetd.conf file. In most circumstances, the only services that would need to run would be time and krdb5_kprop. In addition, any services that use loopback tli (ticlts, ticotsord, and ticots) can be left enabled. After you edit the file, it should look similar to the following (to shorten the example many comments have been removed):

   kdc1 # cat /etc/inetd.conf # #ident "@(#)inetd.conf 1.33 98/06/02 SMI" /* SVr4.0 1.5 */ . . #name dgram udp wait root /usr/sbin/in.tnamed in.tnamed # #shell stream tcp nowait root /usr/sbin/in.rshd in.rshd #login stream tcp nowait root /usr/sbin/in.rlogind in.rlogind #exec stream tcp nowait root /usr/sbin/in.rexecd in.rexecd #comsat dgram udp wait root /usr/sbin/in.comsat in.comsat #talk dgram udp wait root /usr/sbin/in.talkd in.talkd # #uucp stream tcp nowait root /usr/sbin/in.uucpd in.uucpd # #finger stream tcp nowait nobody /usr/sbin/in.fingerd in.fingerd # # Time service is used for clock synchronization. # time stream tcp nowait root internal time dgram udp wait root internal # . . # 100234/1 tli rpc/ticotsord wait root /usr/lib/gss/gssd gssd #dtspc stream tcp nowait root /usr/dt/bin/dtspcd /usr/dt/bin/dtspcd #100068/2-5 dgram rpc/udp wait root /usr/dt/bin/rpc.cmsd rpc.cmsd 100134/1 tli rpc/ticotsord wait root /usr/lib/ktkt_warnd kwarnd krb5_prop stream tcp nowait root /usr/lib/krb5/kpropd kpropd

   Reboot the KDC server after the changes are made.

2. Restrict access to the hardware that supports the KDC.

   In order to restrict physical access, make sure that the KDC server and its monitor are located in a secure facility. Users should not be able to access this server in any way.

3. Store KDC database backups on local disks or on the KDC slaves.

   Make tape backups of your KDC only if the tapes are stored securely. Follow the same practice for copies of keytab files. It would be best to store these files on a local file system that is not shared to other systems. The storage file system can be on either the master KDC server or any of the slave KDCs.