Chapter 7

Planning for SEAM

This chapter should be studied by administrators who are involved in the installation and maintenance of SEAM. The chapter discusses several installation and configuration issues that administrators must resolve before they install or configure SEAM.

This is a list of the issues that a system administrator or other knowledgeable support staff should resolve:

Why Plan for SEAM?

Before you install 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 that is added to the system. In addition, some changes require a full re-installation, so it is better to consider long-term goals when you planning your SEAM configuration.

Realms

A realm is logical network, similar to a domain, which defines a group of systems that are 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 for cross-realm authentication should be resolved before you configure SEAM.

Realm Names

Realm names can consist of any ASCII string. Usually, the realm name is the same as your DNS domain name, in uppercase. This convention 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 you choose to use a different string, then you can use any string. However, the configuration process requires more work. The use of 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 that you split the realm. The primary factors that determine the number of clients that can be supported are as follows:
- The amount of SEAM traffic that each client generates
- The bandwidth of the physical network
- 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 different geographic regions.
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 you are configuring multiple realms for cross-realm authentication, you need to decide how to tie the realms together. You can establish a hierarchical relationship between the realms that provides automatic paths to the related domains. Of course, all realms in the hierarchical chain must be 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 the /etc/krb5/krb5.conf file on all hosts that use the connection. So, some additional work is required. For an introduction, see "Realms" and for the configuration procedures for multiple realms, see "Configuring Cross-Realm Authentication".

Mapping Host Names Onto Realms

The mapping of host names 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 you are using SEAM, it is strongly recommended that DNS services already be 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 example.com, and the realm name is EXAMPLE.COM, then the principal name for the host should be host/boston.example.com@EXAMPLE.COM. The examples in this book use the FQDN for each host.

For the principal names that include the FQDN of an host, it is important to match the string that describes the DNS domain name in the /etc/resolv.conf file. SEAM requires that the DNS domain name be in lowercase letters when you are entering the FQDN for a principal. The DNS domain name can include uppercase and lowercase letters, but only use lowercase letters when you are creating a host principal. For example, it doesn't matter if the DNS domain name is example.com, Example.COM, or any other variation. The principal name for the host would still be host/boston.example.com@EXAMPLE.COM.

SEAM can run without DNS services, but some key capabilities, such as the ability to communicate with 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@EXAMPLE.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. However, if you change the port numbers, then the /etc/services and /etc/krb5/krb5.conf files must 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 as the master KDC does. The slave KDCs provide backup if the master becomes 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 so, a KDC must 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. By adding more slave KDC servers, you 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 that are 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 breach.

In addition, one or more slave KDCs can easily be configured to be swapped with the master KDC. The advantage to following this procedure on at least one slave KDC 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 KDC. For instructions on how to configure a swappable slave KDC, see "Swapping a Master KDC and a Slave KDC".

Database Propagation

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

In large installations with many KDCs in one realm, it is possible for one or more slaves to propagate the data so that the process is done in parallel. This strategy 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 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 feature 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 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 the use of NTP is not required. However, some form of synchronization should be used to prevent access failures because of clock skew.


	Chapter 7 Planning for SEAM This chapter should be studied by administrators who are involved in the installation and maintenance of SEAM. The chapter discusses several installation and configuration issues that administrators must resolve before they install or configure SEAM. This is a list of the issues that a system administrator or other knowledgeable support staff should resolve: "Realms" "Mapping Host Names Onto Realms" "Client and Service Principal Names" "Ports for the KDC and Admin Services" "Slave KDCs" "Database Propagation" "Clock Synchronization" Why Plan for SEAM? Before you install 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 that is added to the system. In addition, some changes require a full re-installation, so it is better to consider long-term goals when you planning your SEAM configuration. Realms A realm is logical network, similar to a domain, which defines a group of systems that are 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 for cross-realm authentication should be resolved before you configure SEAM. Realm Names Realm names can consist of any ASCII string. Usually, the realm name is the same as your DNS domain name, in uppercase. This convention 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 you choose to use a different string, then you can use any string. However, the configuration process requires more work. The use of 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 that you split the realm. The primary factors that determine the number of clients that can be supported are as follows: The amount of SEAM traffic that each client generates The bandwidth of the physical network 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 different geographic regions. 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 you are configuring multiple realms for cross-realm authentication, you need to decide how to tie the realms together. You can establish a hierarchical relationship between the realms that provides automatic paths to the related domains. Of course, all realms in the hierarchical chain must be 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 the `/etc/krb5/krb5.conf` file on all hosts that use the connection. So, some additional work is required. For an introduction, see "Realms" and for the configuration procedures for multiple realms, see "Configuring Cross-Realm Authentication". Mapping Host Names Onto Realms The mapping of host names 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 you are using SEAM, it is strongly recommended that DNS services already be 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 `example.com`, and the realm name is `EXAMPLE.COM`, then the principal name for the host should be `host/boston.example.com@EXAMPLE.COM`. The examples in this book use the FQDN for each host. For the principal names that include the FQDN of an host, it is important to match the string that describes the DNS domain name in the `/etc/resolv.conf` file. SEAM requires that the DNS domain name be in lowercase letters when you are entering the FQDN for a principal. The DNS domain name can include uppercase and lowercase letters, but only use lowercase letters when you are creating a host principal. For example, it doesn't matter if the DNS domain name is `example.com`, `Example.COM`, or any other variation. The principal name for the host would still be `host/boston.example.com@EXAMPLE.COM`. SEAM can run without DNS services, but some key capabilities, such as the ability to communicate with 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@EXAMPLE.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. However, if you change the port numbers, then the `/etc/services` and `/etc/krb5/krb5.conf` files must 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 as the master KDC does. The slave KDCs provide backup if the master becomes 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 so, a KDC must 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. By adding more slave KDC servers, you 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 that are 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 breach. In addition, one or more slave KDCs can easily be configured to be swapped with the master KDC. The advantage to following this procedure on at least one slave KDC 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 KDC. For instructions on how to configure a swappable slave KDC, see "Swapping a Master KDC and a Slave KDC". Database Propagation The database that is stored on the master KDC must be regularly propagated to the slave KDCs. One of the first issues to resolve is how often to update the slave KDCs. The desire to have up-to-date information that is available to all clients needs to be weighed against the amount of time it takes to complete the update. For more information about database propagation, see "Administering the Kerberos Database". In large installations with many KDCs in one realm, it is possible for one or more slaves to propagate the data so that the process is done in parallel. This strategy 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 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 feature 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 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 the use of NTP is not required. However, some form of synchronization should be used to prevent access failures because of clock skew.