9.2 Planning

The first step is a planning stage. Here we evaluate the current setup and the requirements that the new Kerberos realms need to fulfill, and balance those against the cost constraints involved with the project. During this planning stage, we will sketch out the new Kerberos realm structure, define what set of users each Kerberos realm will contain, and finally, prepare the necessary systems to install the Kerberos KDC software.

9.2.1 Planning the Kerberos Realms

The first decision to make when implementing Kerberos is whether there will be multiple Kerberos realms, and if so, what their relationship to each other will be. We've decided to split the organization into three realms to enforce the separation between the three functions of the ISP, namely, the production/business operations, the Unix servers involved in the customer support and hosting functions, and the lab, which is isolated from everything else.

In this case, one realm is already established: the Windows Active Directory domain. This domain was established as SAMPLE.COM, which is also the ISP's DNS domain name. There are two more realms that we will establish as part of this example, named UNIX.SAMPLE.COM and LABS.SAMPLE.COM. We will create them as subdomains of the existing SAMPLE.COM realm to make the cross-realm relationships easier—the hierarchical realm structure creates an implicit certification path for cross-realm authentication, as we saw in Chapter 8.

With the realm names out of the way, we need to establish trust relationships between the realms, if any. Remember that a trust relationship between realms does not automatically provide access to resources in one realm from the trusted realm. However, with that limitation in mind, it is still important to create a layered approach to security, and we want to restrict the trust relationships of the Kerberos realms as much as possible. While this does force users who wish to use resources in both realms to login to both realms, it enforces the administrative and security separation between the Kerberos realms.

Considering the above, we'll separate the LABS.SAMPLE.COM realm from the production SAMPLE.COM and UNIX.SAMPLE.COM realms, to enforce the separation of the testing environment in the labs realm from the production realms. A two-way cross-realm trust is established between the two production realms, SAMPLE.COM and UNIX.SAMPLE.COM, in order to enable sharing of resources between the two realms with one set of credentials. Figure 9-1 depicts the Kerberos realms that are involved, and the trust relationships between them.

Figure 9-1. Sample ISP's Kerberos realm layout

9.2.2 Existing Network Layout

With the conceptual model in mind, let's go a little deeper and examine the hosts that are members of each Kerberos realm. Since this is an example, we'll keep it simple and limit the number of machines to make things easy to follow. Figure 9-2 shows the hosts involved in our sample network, their IP addresses, and what Kerberos realm each host belongs to.

Our existing network has been assigned the 192.168.0.0/16 network block, and is divided into several subnets to separate out the production network, customer hosting network, and lab networks. In the production network, 192.168.1.0/24, there is a Microsoft Active Directory server for the SAMPLE.COM domain that also serves as the Exchange server, known as exchange.sample.com. A Windows desktop machine is a member of the SAMPLE.COM domain, with a DNS name of desktop.sample.com. At the conclusion of this example, it should be possible for technical support personnel to login to the Windows desktop machine and transparently access their accounts on the Unix servers in the hosting.sample.com domain.

Also notable in the production network are several Unix hosts that will be part of the UNIX.SAMPLE.COM realm. The host dns.sample.com handles DNS for the Sample ISP, as well as providing a stratum-2 NTP service for the rest of the Sample ISP network. We'll use it as our time-synchronization source for Kerberos.

Next, the customer web-hosting subnet at 192.168.2.0/24 contains several Unix-based web servers that will be members of the new UNIX.SAMPLE.COM Kerberos realm. These servers all have DNS suffixes of hosting.sample.com, indicating that they are part of the customer subnet.

Note that there are Unix servers scattered about both the customer subnet and production subnet. While these Unix servers are all part of the UNIX.SAMPLE.COM Kerberos realm, they have differing DNS suffixes, and as such, some special care needs to be taken when creating our krb5.conf file. Namely, the domain_realm stanza will need to have explicit entries to map these hostnames to the correct Kerberos realm. This problem could have been avoided by changing the hostnames of the systems in the UNIX.SAMPLE.COM realm to have a DNS domain suffix of unix.sample.com, but there could be instances where this is not practical, as other software may depend on the existence of the current hostname.

Finally, the lab subnet at 192.168.3.0/24 contains the separate lab machines used for testing. This network is kept separate from the other two in order to prevent any experimental applications running on the network from interfering with the production systems located on the other two networks.

9.2.3 Kerberos KDC Planning

With the Kerberos realms mapped out, now we can begin planning the implementation details for each of our new realms. Figure 9-2 shows some planning activity. In that figure, there are two KDCs (unixkdc1 and unixkdc2) for the UNIX.SAMPLE.COM realm, and they are located in the production subnet. A conscious decision was made to replicate the data located in this important realm onto two machines, to ensure high availability. In addition, because of the sensitive nature of the data located on these servers, they are separated from the customer hosting network, presumably behind a restrictive firewall that prevents attackers from gaining access to the KDCs from the hosting network, in the case one of the customer hosting machines is compromised.

Figure 9-2. Sample ISP's network layout

Similar reasoning is used for the LABS.SAMPLE.COM Kerberos KDC placement. Only one KDC is deemed necessary for the labs realm, as it is used for experimental purposes and not for production. The KDC is placed inside the lab network to further isolate the lab environment from the rest of the network.

Next, the hardware and operating system need to be selected for these new Kerberos realms. A powerful machine is not required; the number of principals that will be located in either of these 2 realms is not great, probably under 100. Therefore, a mid-range, Intel-based machine running a free operating system, such as Linux or FreeBSD, fits the bill perfectly. We use FreeBSD for our examples, but any operating system will do.

Since this is an example, we will use two different Kerberos implementations for UNIX.SAMPLE.COM and LABS.SAMPLE.COM. The first, UNIX.SAMPLE.COM, will use the MIT Kerberos 5 implementation, while LABS.SAMPLE.COM will use the Heimdal Kerberos implementation. This is somewhat of an arbitrary decision, as any of the available Kerberos KDCs would work fine in this circumstance. Continuing with the software decisions, we must decide what additional services, if any, to run on the KDC machines. OpenSSH is a good choice to provide remote access for management purposes, but no other services are installed in order to ensure the security of the KDCs.

Disk layout and backup strategy are important to consider during planning. As these machines will contain data (the Kerberos database) that is not easily replaceable and needs to be always available, it is a good idea to place the Kerberos software and database on a separate, hardware, RAID-mirrored disk set. This RAID1 disk will contain only the Kerberos software and database, and will be backed up on a regular basis. Placing the Kerberos software along with the database on this separate disk has the advantage that the backup image can be restored to a spare machine and service restored quickly, as the entire Kerberos KDC is self-contained within the backup image. Reestablishing the Kerberos authentication service would take significantly more time if the Kerberos software had to be restored from a separate backup, or recompiled and reinstalled from scratch.

Another idea, which can be more practical in today's world of large, hard disk platters, is to place everything on one mirrored disk set. Partitions should be established on the disk to ensure that logs and other temporary space do not fill up the entire disk and affect operations of the Kerberos server. The server can be imaged with software such as Symantec's Ghost for Intel-based systems, and periodic dumps can be made of the Kerberos database directory. In either of these techniques, a cold spare can be brought online quickly by restoring the image onto the cold spare system. We'll use this latter technique in our example.

Finally, there are some Kerberos-specific parameters that can be tweaked when installing new Kerberos realms. These include the maximum ticket lifetime, the maximum renewable ticket lifetime, and the option to allow forwardable/addressless tickets. In this example, we won't need to tweak any of these parameters; if you want to adjust the default lifetime parameters, you can use settings in MIT's kdc.conf file, or you can specify different settings in response to prompts when Heimdal initializes the realm. The remaining properties can be set on a per-principal basis through kadmin. See the Appendix for details.