Chapter 2 Planning for SEAM

This chapter should be studied by individuals involved in the installation and maintenance of SEAM. The chapter includes a discussion of several installation and configuration considerations that you must resolve before installing or configuring SEAM.

This is a list of the issues that should be resolved by a System Administrator or other knowledgeable support staff:

• "Realms"

• "Mapping Hostnames Onto Realms"

• "Client and Service Principal Names"

• "Slave KDCs"

• "Database Propagation"

• "Clock Synchronization"

• "SEAM Preconfiguration Procedure"

SEAM Configuration Decisions

Before installing SEAM, you must resolve several configuration issues. Although changing the configuration after the initial install is not impossible, it becomes more difficult with each new client added to the system. In addition, some changes require a full re-installation, so it is better to consider long-term goals when planning.

Realms

A realm is logical network, like a domain, which defines a group of systems under the same master KDC. As with establishing a DNS domain name, issues such as the realm name, the number and size of each realm, and the relationship of a realm to other realms should be resolved before configuringing SEAM.

Realm Names

Realm names can be any ASCII string. Usually it is the same as your DNS domain name, in uppercase. This helps differentiate problems with SEAM from problems with the DNS namespace, while using a name that is familiar. If you do not use DNS or choose to use a different string, then you can use any string, although using realm names that follow the standard internet naming structure is wise.

Number of Realms

The number of realms that your installation requires depends on several factors:

• The number of clients to be supported. Too many clients in one realm makes administration more difficult and eventually requires splitting the realm. The primary factors that determine the number of clients that can be supported are: the amount of SEAM traffic that each client generates, the bandwidth of the physical network and the speed of the hosts. Since each installation will have different limitations, there is no rule for determining the maximum number of clients.

• How far apart the clients are. It might make sense to set up several small realms if the clients are in a different geographic region.

• The number of hosts that are available to be installed as KDCs. Each realm should have at least two KDC servers (master and slave).

Realm Hierarchy

When configuring multiple realms, you need to decide how to tie the realms together. You can establish a hierarchical relation between the realms that provides automatic paths to the related domains, but requires that all realms in the hierarchical chain are configured properly. The automatic paths can ease the administration burden; however, if there are many levels of domains, you might not want to use the default path because it requires too many transactions.

You can also choose to establish the connection directly. A direct connection is most useful when too many levels exist between two hierarchical domains or when there is no hierarchal relationship. The connection must be defined in /etc/krb5/krb5.conf on all hosts using the connection, so some additional work required. See "Realms" for an introduction and "Configuring Cross-Realm Authentication" for the configuration procedures for multiple realms.

Mapping Hostnames Onto Realms

Mapping hostnames onto realm names is defined in the domain_realm section of the krb5.conf file. These mappings can be defined for a whole domain and for individual hosts, depending on the requirements. See the krb5.conf(4) man page for more information.

Client and Service Principal Names

When using SEAM, it is preferable if DNS services are already configured and running on all hosts. If DNS is used, it must be enabled on all systems or on none of them. If DNS is available, then the principal should contain the Fully Qualified Domain Name (FQDN) of each host. For example, if the host name is boston, the DNS domain name is acme.com, and the realm name is ACME.COM, then the principal name for the host should be host/boston.acme.com@ACME.COM. The examples in this book use the FQDN for each host.

For the principal names which include the FQDN of an host, it is important to match the string describing the DNS domain name in /etc/resolv.conf. This string is case-sensitive. SEAM requires that the DNS domain name be in lower case letters, so only lower case letters are used when entering the FQDN for a principal.

SEAM can run without DNS services, but some key functionality, like the ability to communicate to other realms, will not work. If DNS is not configured, then a simple host name can be used as the instance name. In this case the principal would be host/boston@ACME.COM. If DNS is enabled later, all host principals must be deleted and replaced in the KDC database.

Ports for the KDC and Admin Services

By default, port 88 and port 750 are used for the KDC and port 749 is used for the KDC administration daemon. Different port numbers can be used, but changing them requires that the /etc/services and /etc/krb5/krb5.conf files be changed on every client. In addition the /etc/krb5/kdc.conf file on each KDC must be updated.

Slave KDCs

Slave KDCs generate credentials for clients just like the master KDC. The slave KDCs provide backup in case the master is unavailable. Each realm should have at least one slave KDC. Additional slave KDCs might required, depending on these factors:

• The number of physical segments in the realm. Normally, the network should be set up so that each segment can function, at least minimally, without the rest of the realm. To do this requires a KDC to be accessible from each segment. The KDC in this instance could be either a master or a slave.

• The number of clients in the realm. Adding more slave KDC servers can reduce the load on the current servers.

It is possible to add too many slave KDCs. Remember that the KDC database must be propagated to each server, so the more KDC servers installed, the longer it can take to get the data updated throughout the realm. Also, since each slave retains a copy of the KDC database, more slaves increase the risk of a security compromise.

In addition, one or more of the slave KDCs can be configured to be swapped easily with the master KDC. The advantage to following this procedure on at least one of the slave KDCs is that if the master KDC fails for any reason, you will have a system preconfigured that will be easy to swap as the master. See "Swapping Master and Slave KDCs" for instructions on how to configure a swappable slave KDC.

Database Propagation

The database stored on the master KDC must be regularly propagated to the slave KDCs. One of the first issues to be resolved is how often to update the slave KDCs. The desire to have up-to-date information available to all of the clients needs to be weighed against the amount of time it takes to complete the update. See "Administering the Kerberos Database" for more information about database propagation.

In large installations, with many KDCs in one realm, it is possible for one or more of the slaves to propagate the data so that the process is done in parallel. This reduces the amount of time that the update takes, but it also increases the level of complexity in administering the realm.

Clock Synchronization

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, requests are rejected.

One way to synchronize all of the clocks is to use the Network Time Protocol (NTP) software (see "Synchronizing Clocks between KDCs and SEAM Clients" for more information). Other ways of synchronizing the clocks are available, so using NTP is not required. Some form of synchronization should be used to prevent access failures due to clock skew.

SEAM Preconfiguration Procedure

The SEAM product includes a preconfiguration procedure that stores information on an NFS server. The information can then be used by the software installation script. Using the procedure is optional, but strongly recommended because using it saves time during the installation process and reduces errors from manual data entry.