Planning Domain Trees

To create a domain structure that meets the business requirements, you must first have a thorough understanding of how certain operations occur between domains (certain operations that occur in a domain might occur differently between domains). When you're planning domain trees, an understanding of the following topics is necessary:

• Accessing resources between domains

• Authentication across domains

• Types of trust relationships

• Creating an empty root domain

Accessing Resources Between Domains

A new security feature in Windows 2000 is its support for the Kerberos version 5 protocol, an industry-supported authentication protocol that is responsible for the authentication of users across domains. (The Kerberos protocol is discussed in more detail in the next section.) One of the features of the Kerberos version 5 protocol is the transitive trust. In Chapter 2 you learned that, in a multiple-domain structure, two-way transitive trusts are automatically configured between parent domains and child domains in a forest. This enables users to be granted permissions to resources throughout the forest.

When a user attempts to access a resource located in another domain in the forest, the transitive trust path is followed. For example, in Figure 8.2, if a user from the Paris domain attempted to access a resource located in the NY domain, the trust path would have to be followed. The user would first receive authorization from the xyz.corp domain (because Paris has a transitive trust with this domain); then the user would receive authorization from the NY domain.

Figure 8.2. When resources are accessed in another domain in the forest, the trust path must be followed.

Authentication Across Domains

Authentication is the process of confirming the identity of a user attempting to gain access to network resources. Before a user in one domain can access resources in another domain in the forest, she must be authenticated. As already mentioned, the Kerberos version 5 protocol is responsible for authentication across domains. When support is included for this industry-standard security protocol, users need only provide a single username and password at logon to gain access to resources throughout the forest.

Before a user is granted access to resources in another domain, however, the Key Distribution Center (KDC) from each domain in the trust path must authenticate her.

The Key Distribution Center has two roles: It is responsible for authenticating users, and it is responsible for issuing session tickets to users so they can identify themselves to other domains.

Referring to Figure 8.2, if a user from the Paris domain attempted to access a resource located on a server in the NY domain, the following authentication process would occur:

1. When the user attempts to access a resource in the NY domain, the KDC in the user's own domain ”in this case, Paris ”issues the user a session ticket. The session ticket simply identifies the user to other servers in the forest.

2. Following the trust path, the user presents her session ticket to the KDC in the xyz.corp domain.

3. The user is then issued another session ticket from the KDC in the xyz.corp domain, which identifies the user to the next domain in the trust path.

4. The user presents the session ticket to the KDC in the NY domain and is issued a session ticket for the server that contains the resource.

5. After the user presents her session ticket to the server with the desired resource, she is granted the appropriate access to that resource.

This authentication process is completely transparent to the user.

Types of Trust Relationships

Three types of trust relationships can be implemented in Windows 2000 to allow users to gain access to resources located in other domains: transitive, shortcut, and external trusts. Transitive trusts are automatically established, whereas shortcut and external trusts must be explicitly defined.

Transitive Trusts

Transitive trusts are two-way trusts that are automatically created between parent domains and child domains, as well as between the root domain of a forest and any new trees. The trust path created from transitive trusts makes resources throughout the forest accessible to all users. Figure 8.3 shows the default transitive trusts created for the XYZ Corporation's forest.

Figure 8.3. Transitive trusts are established between all parent domains and child domains. They are also created between the forest root and any new trees.

Shortcut Trusts

As already mentioned, when a user attempts to access a resource in another domain in the forest, the trust path must be followed. Depending on the structure of the Active Directory hierarchy, the trust path between two separate domains can be long.

In cases such as this, creating a shortcut trust can shorten the trust path. A shortcut trust is basically a transitive trust (a two-way trust); the difference is that it must be explicitly defined or created. Creating a shortcut trust between two separate domains in a forest can improve the authentication process discussed in the previous section.

For example, the trust path automatically created between the domains and trees in the XYZ Corporation would require that a user from the Paris domain be authenticated at a minimum of three KDCs from three separate domains before being able to access a resource in the NJ domain. To optimize the authentication process between these two domains, a shortcut trust could be defined between them, as shown in Figure 8.4.

Figure 8.4. Creating a shortcut trust between two domains can shorten and therefore improve the authentication process.

External Trusts

The third type of trust that can be implemented is an external trust. External trusts are similar to the trusts set up between Windows NT 4.0 domains; they are one-way trusts and must be manually created.

External trusts can be created between Windows 2000 domains and Windows NT domains. They are also possible between Windows 2000 domains in different forests. External trusts are one way and are not transitive. So, when they're created between Windows 2000 domains in different forests, the trust link individual domains, not the forests.

In a forest, two-way trusts are automatically established; however, by default no trusts are established between separate forests. If users need to access resources located in another forest, an external trust must be established. Remember that external trusts are one way, so if the need to share resources between two forests goes both ways, two external trusts must be created.

For example, if users in the NY domain needed access to resources located in the Sales domain in another forest, an external trust would have to be created.

One important point to keep in mind when creating external trusts is that they apply only to the domains specified. Any other trusts that a domain has remain separate from the external trusts. In other words, if A and B share a transitive trust and an external trust is defined between B and C, there is still no trust between A and C.

In Figure 8.5, the one-way external trust is defined between the NY domain and the Sales domain to give NY users access to resources in Sales. The external trust, however, does not give users access to any other domains in the LMO Corporation.

Figure 8.5. An external trust can be created to give users access to resources located in another forest.

Table 8.1 summarizes the three types of trusts that can be created.

Table 8.1. Three Types of Trusts

Trust	Description
Transitive	A two-way trust that is automatically established between parent domains and child domains as well as any trees in the forest
Shortcut	A two-way transitive trust that must be manually created between two domains to shorten the trust path
External	A one-way trust that must be manually created between domains in separate forests

Creating an Empty Root Domain

In an Active Directory hierarchy with multiple domains, the design team might choose to create an empty forest root domain. This domain would not contain any OUs, and the only users in this domain would be the members of the Enterprise Admins group . The empty forest root domain would establish the namespace that would be inherited by child domains.

Creating an empty forest root domain would be appropriate for a business that wants to maintain a contiguous namespace throughout the organization while allowing for decentralized administration. For example, say the XYZ Corporation wants to maintain decentralized administration for its two business divisions while maintaining a contiguous namespace that identifies each division as part of the corporation. To meet the business's requirements, an empty forest root domain could be created to establish the namespace. Separate domains could then be created for each business division under the forest root that would allow for decentralized administration of each division.

Now that you're familiar with how some of the operations occur in a multiple-domain structure, let's take a look at some of the guidelines that need to be considered when designing multiple domains.