The Basic Steps Planning Your Installation

4.1 The Basic Steps

Well begin by outlining the steps for establishing a Kerberos realm. During this chapter, well follow these steps to create a sample Kerberos realm: 1. 1. Plan your installation. 2. 2. Install the KDC software. 3. 3. Establish the Kerberos realm and create an administrative user principal. 4. 4. Add user principals to your realm. 5. 5. Install Kerberized server software, and install service principals for the server software as necessary. [ Team LiB ] [ Team LiB ]

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 youll be using Kerberos for. The answer to this question depends on whether youll need compatibility with Kerberos 4 clientsservices or not. Well handle the simple case where you have no need to service Kerberos 4 clients or services first. In this case, youll be able to implement a Kerberos 5-based solution with no need for backwards compatibility with Kerberos 4-based systems. All of the KDCs well 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, youll need to plan a bit more carefully to integrate those legacy components into your Kerberos implementation. Typically, in this situation, youll 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. Well talk about this option in more detail in Chapter 8 . Youll want to determine the number of KDCs youll deploy in your network. Since authentication requests to the KDC can be easily handled with todays 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 wont 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 OReilly. You should take into consideration not only how many authentication clients youll 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. [ Team LiB ] [ Team LiB ]

4.3 Before You Begin