4.2 Planning Your Installation

Your Kerberos implementation will be an important part of your network. As such, the Kerberos service needs to be always available, responsive, and in the event of failure, easily restored from backup. Therefore, integrating Kerberos authentication into your network calls for some planning.

The first consideration is what exactly you'll be using Kerberos for. The answer to this question depends on whether you'll need compatibility with Kerberos 4 clients/services or not. We'll handle the simple case where you have no need to service Kerberos 4 clients or services first.

In this case, you'll be able to implement a Kerberos 5-based solution with no need for backwards compatibility with Kerberos 4-based systems. All of the KDCs we'll cover here will be able to handle Kerberos 5 clients, and there will be no need to enable any optional Kerberos 4 compatibility.

On the other hand, if you have to support Kerberos 4 services or clients, you'll need to plan a bit more carefully to integrate those legacy components into your Kerberos implementation. Typically, in this situation, you'll want to stick with a Unix-based KDC, since these have built-in support for the older Kerberos 4 protocol.

Your only option when dealing with Kerberos 4 client machines (machines which will be authenticating end users) is to use a KDC with direct support for Kerberos 4. This limits you to Unix-based KDCs. However, if you are supporting a Kerberos 4-based service (such as AFS), you can get away with a mixture of a Windows domain controller (or another KDC that supports only Kerberos 5 directly) and a machine that is running the Kerberos 5-to-4 ticket translator daemon (known as krb524) that is included with both MIT and Heimdal. We'll talk about this option in more detail in Chapter 8.

You'll want to determine the number of KDCs you'll deploy in your network. Since authentication requests to the KDC can be easily handled with today's overpowered processors, a single or dual processor machine should suffice for thousands of clients. Note that this applies to Unix-based system running only a KDC; Windows domain controllers function as much more than just a Kerberos KDC and therefore may have a higher server-to-client ratio than a dedicated Unix KDC. I won't go into detail about Active Directory planning here; readers interested in more detailed discussion about Active Directory should refer to Active Directory by Robbie Allen and Alistair G. Lowe-Norris (O'Reilly).

You should take into consideration not only how many authentication clients you'll be serving, but also where these clients are located. While the bandwidth requirements for Kerberos authentication are miniscule, the important metric for Kerberos performance is the network latency between clients and the Kerberos KDCs. Each authentication exchange requires time for at least one full round trip between client and KDC, and if this latency is long—for example, traveling through a satellite uplink or across congested Internet backbones—then users' authentication requests will become noticeably slow. Consequently, you want to position your KDCs so that they are as close to the clients network-wise as possible.

Of course, when rolling out a system as complex as Kerberos, you'll want to do a test run first, to become familiar with the system before performing a more substantial roll out to a larger user population.

4.2.1 Choose the Platform and Operating System

The choice of platform and operating system is made for you if you're using a Windows domain controller as your KDC; however, if you're using a Unix-based KDC, you'll have to consider what platform you'll run the KDCs on. Any reasonably modern machine will be able to handle the load of running the KDC software; the real concern when choosing a platform to run your Kerberos KDCs is reliability.

As a general rule, when your Kerberos KDC is unavailable, your users cannot acquire Kerberos tickets to authenticate to Kerberized services. Note that any tickets that clients may have in their credential caches will continue to work, but any attempts to acquire new service tickets during a KDC outage will fail. Mirrored RAID for your Kerberos database is a good idea, as well as stable hardware from a vendor with good support and spare parts.

Finally, consider disk layout issues when installing the operating system on your KDCs. We strongly recommend that a separate disk (or better yet, a RAID set of disks) be used to hold the Kerberos database, and a separate partition used to hold all log files. Keeping log files in a separate partition prevents either inadvertent or intentional log file overflows from affecting the system or Kerberos database partitions.

4.2.2 Choose a KDC Package

If you are establishing a new Kerberos realm, you'll need to start by choosing a Kerberos implementation for your KDC. There are many different KDCs available from different vendors, both commercial and open source. Each KDC implementation is different, with advantages and disadvantages over the others. Let's start by reviewing each KDC package we'll cover in detail.

Don't ignore your existing infrastructure. If you're a large organization or you've got an existing Windows domain, chances are that you already have a Kerberos KDC available. By the same token, if you're a predominantly Windows-based shop, you should strongly consider a Windows 2000 or 2003-based KDC, and vice versa for a Unix shop. The different implementations have enough of the essential features in common that the choice comes down to familiarity and comfort with the platform required to run the software.

Unlike Kerberos clients, you can't mix Kerberos KDC implementations. An MIT Kerberos KDC, for example, cannot replicate against a Windows domain controller (yet). In addition, each Kerberos implementation uses a different administration protocol. That is, the administrative interface contained with the MIT KDC cannot be used, for example, to add users to a Heimdal KDC, and vice versa.

4.2.2.1 MIT

We'll begin with MIT since it's the first, and still the reference implementation for both Kerberos 4 and Kerberos 5. Many large institutions, mostly universities, use MIT KDCs to handle authentication. There's a large support base for MIT Kerberos and it is used in many environments, which helps to exercise bugs out of the system.

MIT Kerberos contains support for the standard Kerberos encryption types, notably single and triple DES. In addition, the latest version of MIT Kerberos, 1.3, includes support for the RC4 encryption type used by the Microsoft Active Directory Kerberos service as well as the new Advanced Encryption Standard (AES). MIT is a great choice because of its wide support and appliction compatibility.

4.2.2.2 Heimdal

Heimdal is a slightly newer player to the game, and like MIT, contains full support for Kerberos 5, Kerberos 4, and the ticket translator. Since it is developed overseas and, as such, is unencumbered by any export restrictions, Heimdal enjoys considerable support outside the U.S.

There are several improvements that come out of the box with Heimdal over MIT Kerberos. First, Heimdal supports incremental database propagation, which allows Heimdal KDCs to send only the changed portions of the Kerberos database to slave servers when it is updated, instead of transmitting the entire database every time an update is made. Also, Heimdal includes integrated support for AFS-Kerberos 5 interoperability. However, Heimdal's Kerberos 5 API and GSSAPI differ slightly from MIT's, such that most Kerberos applications do not compile out of the box with the Heimdal Kerberos 5 libraries.

Recent versions of Heimdal Kerberos also contain support for the same encryption types supported by MIT Kerberos; namely, single and triple DES, AES, and RC4.

Heimdal is integrated with several free operating systems, including the BSDs: OpenBSD, NetBSD, and FreeBSD. Its popularity among these distributions can be attributed to the fact that it is unencumbered by export regulations, and so no special exceptions have to be made when distributing software outside of the U.S. Because of its integration with various free Unixes, Heimdal makes a good choice if you are planning on using one of those Unix varieties to host your KDC.

4.2.2.3 Windows domain controllers

The Kerberos implementation contained in Windows 2000 and above is the newest of the bunch. The Windows implementation only supports Kerberos 5 and does not support any of the backwards-compatibility features that MIT and Heimdal include for Kerberos 4 clients. This becomes a problem if you have Kerberos 4-only clients. If you have Kerberos 4-only services, such as AFS, you can still run a Windows domain controller, but you will also need a Unix machine to run the MIT krb524d daemon.

The Windows domain controller supports only the RC4 encryption type as well as the older DES encryption type. It does not support the newer Triple DES that MIT and Heimdal support. There are also several other peculiarities in the Windows KDC that need to be kept in mind; we'll cover these later in the chapter.