Kerberos: The Definitive Guide

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 ...