Chapter 3 Configuring SEAM

This chapter provides configuration procedures for KDC servers, 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. Cross-realm configuration procedures and other topics related to the KDC servers are also covered.

• "Configuring KDC Servers"

• "Configuring Cross-Realm Authentication"

• "Configuring SEAM Network Application Servers"

• "Configuring SEAM NFS Servers"

• "Configuring SEAM Clients"

• "Synchronizing Clocks between KDCs and SEAM Clients"

• "Swapping Master and Slave KDCs"

• "Administering the Kerberos Database"

• "Increasing Security"

SEAM Configuration 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, and can be done when appropriate. The table below shows a suggested order for a SEAM installation.

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

Configuring KDC Servers

After installing 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 attempting other tasks.

The most significant difference between a master and a slave KDC is that only the master 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 and master KDCs generate credentials; this provides redundancy in case the master KDC is not able to respond.

How to Configure a Master KDC

To provide a complete example, assume that you did not run the preconfiguration procedure. If you used the preconfiguration procedure when installing the software, then many of the files included in this procedure do not need to be edited; however, you should review the file contents.

In this procedure 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

• admin principle = 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 SEAM Installation and Release Notes.

  ---

1. Prerequisites for configuring a master KDC.

   This procedure requires that the master KDC software is installed. In addition, DNS must be running. See "Swapping Master and Slave KDCs" for specific naming instructions if this master is to be swappable.

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. If you installed the SEAM software using the configuration files, verify the contents of the file instead of editing it.

   kdc1 # 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 # # 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. The line for domain_realm is included to make the example complete, but this entry will not be created by the installation process if the realm and domain names are equivalent. In addition, the line defining 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. If you installed the SEAM software using the configuration files, verify the contents of the file instead of editing it.

   kdc1 # cat /etc/krb5/kdc.conf [kdcdefaults] kdc_ports = 88,750 [realms] ACME.COM= { profile = /etc/krb5/krb5.conf database_name = /var/krb5/principal admin_keytab = /var/krb5/kadm5.keytab acl_file = /var/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 using kdb5_util.

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

   kdc1 # /usr/krb5/sbin/kdb5_util create -r ACME.COM -s Initializing database '/var/krb5/principal' for realm 'ACME.COM' master key name 'K/M@ACME.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 servers name space domain name.

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

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

   kws/admin@ACME.COM *

   This entry gives the kws/admin principal in the ACME.COM realm the ability to modify principals or policies in the KDC. The default installation includes an "*" to match all admin principals. This could be a security risk, so it is more secure to include a list of all of the admin principals.

7. Start kadmin.local.

   The next sub-steps create principals used by SEAM.

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

   1. Add administration principals to the database using kadmin.local.

      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@ACME.COM: <type the password> Re-enter password for principal kws/admin@ACME.COM: <type it again> Principal "kws/admin@ACME.COM" created. kadmin.local:

   2. Create a keytab file for kadmin using kadmin.local.

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

      kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc1.acme.com Entry for principal kadmin/kdc1.acme.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.acme.com Entry for principal changepw/kdc1.acme.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 using the SEAM Administration Tool. The command line example is shown for simplicity. You must log on with one of the admin principal names that you created earlier in this procedure.

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

   1. Create the master KDC host principal using kadmin.

      The host principal is used by Kerberized applications (such as klist and kprop) as well as Kerberized services (such as ftp and telnet).

      kadmin: addprinc -randkey host/kdc1.acme.com Principal "host/kdc1.acme.com@ACME.COM" created. kadmin:

   2. Optional: Create the master KDC root principal using kadmin.

      This principal is used for authenticated NFS-mounting, and so might not be necessary on a master KDC.

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

   3. Add the master KDCs host principal to the master KDCs keytab file.

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

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

   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. If you installed the SEAM software using the configuration files, verify the contents of the file instead of editing it.

    kdc1 # cat /etc/krb5/kpropd.acl host/kdc1.acme.com@ACME.COM host/kdc2.acme.com@ACME.COM

11. Optional: Synchronize the master KDCs clock using NTP or another clock synchronization mechanism.

    It is not necessary to install and use NTP, but every clock must be within default time 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. To provide a complete example, it is assumed that you did not use the preconfiguration procedure when installing the software or had not defined kdc3 as a slave when running the preconfiguration procedure. If you used the procedure and identified kdc3 as a slave, then many of the files included in this procedure do not need to be edited, but you should review the contents of the files.

This procedure uses the following configuration parameters:

• realm name = ACME.COM

• DNS domain name = acme.com

• master kdc = kdc1.acme.com

• slave kdc = kdc2.acme.com and kdc3.acme.com

• admin principle = 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 SEAM Installation and Release Notes.

  ---

1. Prerequisites for configuring a slave KDC.

   This procedure requires that the master KDC has been configured and that the SEAM slave KDC software has been installed on kdc3. See "Swapping Master and Slave KDCs" for specific instructions if this slave is to be swappable.

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 configuring the master KDC.

   kdc1 # /usr/krb5/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, using kadmin.

      In order for the slave to function, it must have a host principal.

      kadmin: addprinc -randkey host/kdc3.acme.com Principal "host/kdc3@ACME.COM" created. kadmin:

   2. Optional: On the master KDC, create the slave KDC root principal using kadmin.

      This principal is only needed if the slave will be NFS-mounting an authenticated file system.

      kadmin: addprinc root/kdc3.acme.com Enter password for principal root/kdc3.acme.com@ACME.COM: <type the password> Re-enter password for principal root/kdc3.acme.com@ACME.COM: <type it again> Principal "root/kdc3.acme.com@ACME.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.If you defined kdc3 as a slave server when running the preconfiguration procedure, verify the contents of the file instead of editing it.

   kdc1 # cat /etc/krb5/krb5.conf [libdefaults] default_realm = ACME.COM [realms] ACME.COM = { kdc = kdc1.acme.com kdc = kdc2.acme.com kdc = kdc3.acme.com admin_server = kdc1.acme.com } [domain_realm] .acme.com = ACME.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. If you defined kdc3 as a slave server when running the preconfiguration procedure, verify the contents of the file instead of editing it.

   kdc1 # cat /etc/krb5/kpropd.acl host/kdc1.acme.com@ACME.COM host/kdc2.acme.com@ACME.COM host/kdc3.acme.com@ACME.COM

6. On all Slaves: 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. If you defined kdc3 as a slave server when running the preconfiguration procedure, verify the contents of the files instead of copying them. You can use ftp or a similar transfer mechanism to grab copies of the following files from the master:

   • /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 using kadmin.

   You must log on with one of the admin principal names that you created when configuring the master KDC. This entry will allow kprop and other Kerberized applications to function.

   kdc3 # /usr/krb5/sbin/kadmin -p kws/admin Enter password: <Enter kws/admin password> kadmin: ktadd host/kdc3.acme.com kadmin: Entry for principal host/kdc3.acme.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. If you defined kdc3 as a slave server when running the preconfiguration procedure, verify the contents of the file instead of editing it.

   10 3 * * * /usr/krb5/lib/kprop_script kdc2.acme.com kdc3.acme.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 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/krb5/lib/kprop_script kdc3.acme.com Database propagation to kdc3.acme.com: SUCCEEDED

10. On the new slave: Create a stash file using kdb5_util.

    kdc3 # /usr/krb5/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. On the new slave: Start the KDC daemon (krb5kdc).

    kdc3 # /etc/init.d/kdc start

12. Optional: On the new slave, synchronize the master KDCs clock using NTP or another clock synchronization mechanism.

    It is not necessary to install and use NTP, but every clock must be within the default time 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.

Configuring Cross-Realm Authentication

You have several ways of linking realms together so that users in one realm can be authenticated in another. Normally this is accomplished by establishing a secret key to be 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

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

1. Prerequisites for establishing hierarchical cross-realm authentication.

   This procedure requires that the master KDC for each realm has been configured. To fully test the process, several clients or slave KDCs must be installed.

2. Become root on the first master KDC.

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

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

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

   ---

   Note -

   The password entered for each service principal must be identical in both KDCs; which means that the password for krbtgt/ENG.EAST.ACME.COM@EAST.ACME.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.acme.com = ENG.EAST.ACME.COM .east.acme.com = EAST.ACME.COM

   In this example, domain names for the ENG.EAST.ACME.COM and EAST.ACME.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 the 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

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

1. Prerequisites for establishing direct cross-realm authentication.

   This procedure requires that the master KDC for each realm has been configured. To fully test the 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 using kadmin.

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

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

   ---

   Note -

   The password entered for each service principal must be identical in both KDCs; which means that the password for krbtgt/ENG.EAST.ACME.COM@SALES.WEST.ACME.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 (kdc.conf).

   This example is for the clients in the ENG.EAST.ACME.COM realm. You would swap the realm names to get the appropriate definitions in the SALES.WEST.ACME.COM realm.

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

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

   In order for the 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 Network Application Servers

Network application servers are hosts that provide access using one of the following network applications: ftp, rcp, rlogin, rsh, and telnet. Only a few steps are required to enable the SEAM version of these commands on a server.

How to Configure a SEAM Network Application Server

This procedure uses the following configuration parameters:

• application server = boston

• admin principle = kws/admin

• DNS domain name = acme.com

• realm name = ACME.COM

1. Prerequisites for configuring an application server.

   This procedure requires that the master KDC has been configured. To fully test the process, several clients must be installed.

2. Install SEAM client software.

   The SEAM client software must be installed.

3. Optional: Install NTP client or other clock synchronization mechanism.

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

4. Start kadmin.

   Using the SEAM Administration Tool to add a principal is explained in "How to Create a New Principal". The example below shows how to add the required principals using the command line. You must log on with one of the admin principal names that you created when configuring the master KDC.

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

   1. Create the server's host principal.

      kadmin: addprinc -randkey host/boston.acme.com Principal "host/boston.acme.com" created. kadmin:

   2. Optional: Create a root principal for the host principal.

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

   3. Add the server's host principal to the server's keytab.

      If the kadmin command is not running, restart it with a command like: /usr/krb5/sbin/kadmin -p kws/admin

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

   4. Quit kadmin

      kadmin: quit

Configuring SEAM NFS Servers

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, to 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. Start kadmin.

   Using the SEAM Administration Tool to add a principal is explained in "How to Create a New Principal". The example below shows how to add the required principals using the command line. You must log on with one of the admin principal names that you created when configuring the master KDC.

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

   1. Create the server's NFS service principal.

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

   2. Optional: Create a root principal for the NFS server.

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

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

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

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

   See "Setting Up Root Authentication to Mount NFS File Systems" for more information.

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" in System Administration Guide, Volume 2.

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 "SEAM Commands" in System Administration Guide, Volume 2.

# 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

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




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 SEAM Installation and Release Notes.

---

1. Prerequisites for configuring a SEAM client.

   The SEAM client software must be installed.

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

   If you used the preconfiguration procedure, you do not need to edit this file, but you should review the contents. To change the file from the SEAM default version, you need to change the realm names and the names of the servers, as well as identifying the path to the help files for gkadmin.

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

4. Optional: Create a user principal if one does not already exist.

   You only need to create a user principal, if the user associated with this host does not have a principal assigned already. See "How to Create a New Principal" for instructions using the SEAM Administration Tool. A command line example is shown below.

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

5. Create a root principal.

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

6. (Optional) If you want a user on the SEAM client to automatically mount Kerberized NFS file systems using 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 secured by Kerberos. You can choose to use a keytab file instead. See "Setting Up Root Authentication to Mount NFS File Systems" for detailed information about the keytab requirement.

   client1 # /usr/bin/kinit root/client1.acme.com Password for root/client1.acme.com@ACME.COM: <Enter password>

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

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

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

   See warn.conf(4) for more information.

8. Update the user's shell search path to include the location of the SEAM commands and man pages.

   If you installed the SEAM software using the configuration files, and selected to automatically update the PATH definition, you only need to change the MANPATH variable. If you use the C shell, type:

   % set path=(/usr/krb5/bin $path) % set MANPATH=(/usr/krb5/man $MANPATH)

   To permanently affect these changes to your shell search path, edit your .cshrc or .login startup file.

   If you use the Bourne or Korn shell, type:

   $ PATH=/usr/krb5/bin:$PATH $ MANPATH=/usr/krb5/man:$MANPATH

   To permanently affect these changes to your shell search path, edit your .profile startup file.

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 they 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 is true even when the automounter is set up. Not only is this an extra step, but it forces all users to know their system's root password and the root principal's password.

To bypass this, you can add a client's root principal to the client's keytab, which will automatically provide credentials for root. Although this 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, the person has the capability of obtaining credentials for root. So make sure you take the appropriate security precautions. See "Administering Keytabs" for more information.

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 Network Time Protocol (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, 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/or 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 all done through the xntpd daemon, which sets and maintains a UNIX system time-of-day in agreement with Internet standard time servers. Figure 3-1 shows an example of the using the server/client NTP implementation.

Figure 3-1 Synchronizing Clocks 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 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".

How to Set Up an NTP Server

1. Become superuser on the system to be the NTP server.

2. Change to the /etc/inet directory.

3. Copy the ntp.server file to the ntp.conf file.

   # cp ntp.server ntp.conf

4. Change to the /etc/init.d directory.

5. Start the xntpd daemon.

   # ./xntpd start

How to Set Up an NTP Client

1. Become superuser on the system to be an NTP client.

2. Change to the /etc/inet directory.

3. Copy the ntp.client file to the ntp.conf file.

   # cp ntp.client ntp.conf

4. Change to the /etc/init.d directory.

5. Start the xntpd daemon.

   # ./xntpd start

Swapping Master and Slave KDCs

These procedures should be used to make the swapping of a master with a slave KDC easier. This should only be done if the master KDC server fails for some reason or if the master needs to be re-installed (new hardware for example).

How to Configure a Swappable Slave KDC

This procedure should be done on the slave KDC server that you want to have available to become the master.

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

   When defining the hostnames for the KDCs, make sure that each system has an alias included in DNS and use the alias names when defining the hosts in /etc/krb5/krb5.conf.

2. Disable hostname checking in the KDC startup script on both master and swappable slave.

   Using alias names for the master and swappable slave KDC servers means that the check which verifies that the current nodename is in /etc/krb5/krb5.conf before starting the KDC server fails. To use the alias names so that the swapping is easy to do, you need to comment out two lines in /etc/init.d/kdc as shown below:

   if [ -f $KDC_CONF_DIR/kdc.conf ] then # node=`uname -n` # if grep -i "kdc.*=.*$node" /etc/krb5/krb5.conf > /dev/null 2>&1 ; then $BINDIR/krb5kdc fi fi ;;

3. Install master KDC software.

   Installing the master KDC software provides the binaries and other files that will be needed during a swap, which includes all of the files that a slave KDC server requires. Do not reboot the system when the installation is complete.

4. Follow steps to install a slave KDC.

   Prior to any swapping, this server should function just like any other slave KDC in the realm. See "How to Configure a Slave KDC" for instructions. Do not install the slave software. All of the files that are required are installed when the master software is installed.

5. Move master KDC commands.

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

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

6. Disable kadmind startup in /etc/init.d/kdc.master.

   To prevent the slave from handling requests to change the KDC database, comment out the line that starts kadmind in the script:

   kdc4 # cat /etc/init.d/kdc.master . . case "$1" in 'start') if [ -f $KDC_CONF_DIR/kdc.conf ] then # $BINDIR/kadmind fi ;;

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

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

   kdc4 # crontab -e #ident "@(#)root 1.19 98/07/06 SMI" /* SVr4.0 1.1.3.1 */ # # 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 * * 0,4 /etc/cron.d/logchecker 10 3 * * 0 /usr/lib/newsyslog 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/krb5/lib/kprop_script kdc1.acme.sun.com #SUNWkr5ma

How to Swap a Master and 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 server that is being swapped out is named kdc1 and the slave that will become the new master is named kdc4.

1. On the old master: Kill the kadmind process.

   Killing the kadmind process prevents any changes from being made to the KDC database.

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

2. On the old master: Comment out kprop line in the root crontab file.

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

   kdc1 # crontab -e #ident "@(#)root 1.19 98/07/06 SMI" /* SVr4.0 1.1.3.1 */ # # 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 * * 0,4 /etc/cron.d/logchecker 10 3 * * 0 /usr/lib/newsyslog 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/krb5/lib/kprop_script kdc2.acme.sun.com #SUNWkr5ma

3. On the old master: Disable kadmind startup in /etc/init.d/kdc.master.

   To prevent the master from restarting kadmind if the server is rebooted, comment out the line that starts kadmind in the script:

   kdc1 # cat /etc/init.d/kdc.master . . case "$1" in 'start') if [ -f $KDC_CONF_DIR/kdc.conf ] then # $BINDIR/kadmind fi ;;

4. On the old master: Run kprop_script to back up and propagate the database.

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

5. On the old master: Move master KDC commands.

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

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

6. On the DNS server: Change alias names for the master.

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

   masterkdc IN CNAME kdc4

7. On the DNS server: Restart internet domain name server.

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

   # pkill -1 in.named

8. On the new master: Move master KDC commands.

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

9. On the new master: Create a keytab file for kadmin 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/krb5/sbin/kadmin.local kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc4.acme.com Entry for principal kadmin/kdc4.acme.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.acme.com Entry for principal changepw/kdc4.acme.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: Enable kadmind startup in /etc/init.d/kdc.master.

    kdc4 # cat /etc/init.d/kdc.master . . case "$1" in 'start') if [ -f $KDC_CONF_DIR/kdc.conf ] then $BINDIR/kadmind fi ;;

11. On the new master: Start kadmind.

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

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

    kdc4 # crontab -e #ident "@(#)root 1.19 98/07/06 SMI" /* SVr4.0 1.1.3.1 */ # # 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 * * 0,4 /etc/cron.d/logchecker 10 3 * * 0 /usr/lib/newsyslog 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/krb5/lib/kprop_script kdc1.acme.sun.com #SUNWkr5ma

Administering the Kerberos Database

The Kerberos database is the backbone of Kerberos and must be maintained properly. This section provides some of the procedures on how to administer the Kerberos database, such as backing up and restoring the database, setting up parallel progation, and administering the stash file. The steps to set up the database initially can be found 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 slave KDCs will become out-of-sync, 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 for purposes of load balancing, the clients using that slave as a master KDC will not have the latest information. Therefore, it is important to make sure the 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 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 this happens on one of the slave KDCs, you might never notice, since the next automatic propagation of the database installs a fresh copy. However, if it happens to the master KDC, the corrupted database is propagated to all of the slaves 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 is that, 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/write permissions only as root). This includes using only the kprop command to propagate the database dump file, which encrypts the data 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 slaves will not contain the updates: the updates will be lost. Because of this scenario, if you add significant updates to the database before a regularly scheduled propagation, you should manually propagate the database to avoid data loss.

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 the propagation mechanism. 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.

However, the SEAM installation and subsequent configuration steps in this guide instruct you to add the same kpropd.acl file to the master and slave KDCs. The 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, keeping an identical copy on all KDCs makes it easy to maintain.

kprop_script Command

The kprop_script command uses the kprop command to propagate the Kerberos database to other KDCs. (If the kprop_script is run on a slave KDC, it propagates the slave'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 kdb5_util.

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

   -verbose	Prints the name of each principal and policy that is being backed up.
   dbname	The name of the database to back up. Note that ".db" is appended to whatever database name is specified, and an absolute path for the file can be specified. If the -d option is not specified, the default database name is /var/krb5/principal, which actually becomes /var/krb5/principal.db.
   filename	The file to back up the database. An absolute path for the file can be specified. If you don't specify a file, the database is dumped to standard output.
   principal	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 principals, the entire database is backed up.

Example--Backing Up the Kerberos Database

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

# kbd5_util dump -verbose dumpfile 
kadmin/kdc1.eng.acme.com@ENG.ACME.COM 
krbtgt/eng.acme.com@ENG.ACME.COM 
kadmin/history@ENG.ACME.COM 
pak/admin@ENG.ACME.COM 
pak@ENG.ACME.COM
changepw/kdc1.eng.acme.com@ENG.ACME.COM
#

The following example backs up the pak and pak/admin principals from the Kerberos database.

# kdb5_util dump -verbose dumpfile pak/admin@ENG.ACME.COM pak@ENG.ACME.COM
pak/admin@ENG.ACME.COM
pak@ENG.ACME.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/krb5/sbin/kdb5_util load [-verbose] [-d dbname] [-update] [filename]

   -verbose	Prints the name of each principal and policy that is being restored.
   dbname	The name of the database to restore. Note that ".db" is appended to whatever database name is specified, and an absolute path for the file can be specified. 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	The file from which to restore the database. An absolute path for the file can be specified.

Example--Restoring the Kerberos Database

The following example restores the database called database1.db 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 using the kprop command. You can use this if you need to sync 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 database.

1. Become superuser on the master KDC.

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

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

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

   # /usr/krb5/lib/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/krb5/lib/kprop_script slave_KDC

Setting Up Parallel Propagation

In most cases, the master KDC is used exclusively to propagate its database to the slave KDCs. However, if your site has a lot of slave KDCs, you might want to 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 enables the propagation to be done faster and to lighten the work for the master KDC.

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

Figure 3-2 Example Parallel Propagation Configuration

How to Set Up Parallel Propagation

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

   ---

   Note -

   Determining 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 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 3-2, the master KDC's kprop_script entry would look something like this:

10 3 * * * /usr/krb5/lib/kprop_script slave-1.acme.com slave-4.acme.com

slave-1's kprop_script entry would look something like this (note that the propagation on the slave starts an hour after it is propagated by the master):

10 4 * * * /usr/krb5/lib/kprop_script slave-2.acme.com slave-3.acme.com

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

host/master.acme.com@ACME.COM

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

host/slave-1.acme.com@ACME.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 kdb5_util(1M) 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

   stash_file

   The path to the stash file. By default, the stash file is located at /var/krb5/.k5.realm.

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

Increasing Security

These procedures list steps that you can use to increase security on SEAM application servers and on KDC servers.

How to Enable Only Kerberized Applications

This procedure restricts network access to the server using telnet, ftp, rcp, rsh, and rlogin to Kerberos authenticated transactions only.

1. Edit the telnet entry in /etc/inetd.conf.

   Add the -a user option to the telnet entry to restrict access to those users who can provide valid authentication information.

   telnet stream tcp nowait root /usr/krb5/lib/telnetd telnetd -a user

2. Edit the ftp entry in /etc/inetd.conf.

   Add the -a option to the ftp entry to permit only Kerberos authenticated connections.

   ftp stream tcp nowait root /usr/krb5/lib/ftpd ftpd -a

3. Disable Solaris entries for other services in /etc/inetd.conf.

   The entries for shell and login need to be commented out or removed

   # shell stream tcp nowait root /usr/sbin/in.rshd in.rshd # login stream tcp nowait root /usr/sbin/in.rlogind in.rlogind

How to Restrict Access for KDC servers

Both master 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 /etc/inetd.conf.

   To provide a secure KDC server, all non-essential network services should be disabled by commenting out the entry that starts the service in /etc/inetd.conf. 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 editing, the file should look something like (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 #klogin stream tcp nowait root /usr/krb5/lib/rlogind rlogind -k #eklogin stream tcp nowait root /usr/krb5/lib/rlogind rlogind -k -e #telnet stream tcp nowait root /usr/krb5/lib/telnetd telnetd #ftp stream tcp nowait root /usr/krb5/lib/ftpd ftpd #kshell stream tcp nowait root /usr/krb5/lib/rshd rshd -k -c -A krb5_prop stream tcp nowait root /usr/krb5/lib/kpropd kpropd

   Reboot the server after the changes are made.

2. Restrict access to the hardware supporting the KDC.

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

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

   Making tape backups of your KDC should only be done if the tapes are stored securely. This is also true 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 slaves.