4.3 Before You Begin

Kerberos requires the proper functioning of several external services. Notably, the clocks on all machines participating in your realm must be synchronized to within a few minutes, and a working DNS domain should be established with forward and reverse mappings to at least the Kerberos KDC and application servers you intend to Kerberize.

First, NTP (the Network Time Protocol, official home page at http://www.ntp.org/ ) should be installed on every server and KDC in your network. NTP will synchronize the clocks of these machines to a central source, which can be either a local time source (such as a GPS unit receiving time signals from the GPS satellites, or a Cesium time source, if you happen to have an atomic clock available at your site) or a remote Internet-accessible time server. While it is possible to set up all of your machines to synchronize over the network to an external, publicly available time server, site administrators are strongly encouraged to set up a centralized time source for their network, and set up other machines on the network to synchronize to that server. The time server machine can then synchronize to an accurate time source, such as a public time server.

The details of setting up NTP are beyond the scope of this book, and online references and software are readily available from the above URL. Clients will need to be synchronized also, but hand synchronization is sufficient unless you have enough control over the client systems to install NTP on them as well. While Kerberos does require synchronized clocks, Kerberos implementations typically provide for a plus-or-minus five-minute error when comparing times. Even with this built in time slack, poorly synchronized clocks are the root of many problems that are encountered when using Kerberos. Therefore, investing time up front to ensure accurate clocks on all machines on your network is time well spent.

Windows machines that are part of an Active Directory domain automatically synchronize their clocks to the domain controller's clock through the Windows Time Service. Unix systems typically do not have NTP installed and configured out of the box, so manual configuration is required to keep these systems' clocks in sync.

The proper functioning of your DNS server and client DNS resolver libraries are also important, and some time should be spent ensuring that they are functioning properly before installation. Every Unix system has different semantics for what it thinks its own hostname is: some use the fully qualified domain name (hostname plus domain name); others use just the hostname component. And to make matters worse, some Unix systems map their own hostname to 127.0.0.1 (the loopback IP address). Observe the following guidelines to avoid most DNS-related problems when implementing and maintaining your Kerberos system:

Ensure valid forward and reverse DNS mappings for machines in your domain

All machines in your domain that will participate in your Kerberos realm need to have working DNS entries, both forward and reverse. This means that, for every machine, a DNS entry exists that maps the hostname to an IP address, and a reverse entry exists for that IP address mapping it back to the original hostname.

Set all system hostnames to the fully qualified domain names

What a system considers its own hostname to be is important as well. When Kerberos needs to create the name of the host principal, it uses the output from the system's gethostname( ) call to generate the principal name. If this generated principal name doesn't match the host principal that is listed in the KDC's database, then the application will fail with a cryptic error message saying that it can't find the principal. For example, if a host thinks that its hostname is bigserver yet its host principal is host/bigserver.wedgie.org@WEDGIE.ORG, it will attempt to find a host principal of host/bigserver@WEDGIE.ORG and fail.

Ensure that local systems' /etc/hosts file, if used, map the hostname to a valid IP address

Some systems install an /etc/hosts file with an entry such as this:

127.0.0.1              bigserver.wedgie.org   bigserver

This line, which maps the system's hostname to the loopback interface, will most likely cause problems at some point. You should ensure that if an /etc/hosts file is used, that all machine names point to real, network-accessible IP addresses. For example, if bigserver.wedgie.org's IP address is 192.168.1.1, then the /etc/hosts file should contain the following entries:

127.0.0.1                          localhost   bigserver
192.168.1.1                        bigserver.wedgie.org  bigserver