After you define the forest root domain needed for your organization's forests, the next step is to organize the domains in a hierarchy. This lesson explains the process of defining a domain hierarchy, which includes assessing needs, determining the number of domain trees, designating tree root domains, arranging the subdomain hierarchy, and planning cross-link trusts.
After this lesson, you will be able to
Estimated lesson time: 15 minutes
A domain hierarchy is a tree structure of parent and child domains. The way in which domains are arranged in a hierarchy determines the trust relationships between domains. Windows 2000 creates parent-child trusts between parent and child domains in a forest or tree hierarchy. Parent-child trusts are implicit, two-way transitive trusts that are created automatically when a domain is added to the hierarchy, as shown in Figure 4.7.
Figure 4.7 Parent-child trusts
The arrangement of domains in a hierarchy does not need to be based on the organization's administrative structure. Domains that function as peers can have parent and child relationships without affecting administrative control. Although administrators in a parent domain can have administrative rights in the child domain, these rights are not automatic and must be explicitly set up. Likewise, group policies set in a parent domain do not automatically propagate to child domains in the forest; they must be explicitly linked. It's important to remember also that the only group that has administrative rights across domains by default is the Enterprise Admins predefined universal group. Rather than arranging domains for administrative capabilities, arrange them in the hierarchy to take advantage of the implicit, two-way transitive trust between parent and child domains, thus optimizing authentication. For example, in Figure 4.7, the uk.microsoft.com and us.microsoft.com domains often require access to resources in the microsoft.com domain. The arrangement shown provides a short, optimal authentication path.
Although the parent-child trusts used in Windows 2000 have reduced administration time compared to the explicit, one-way nontransitive trusts employed by Windows NT, interdomain authentication must follow the established trust path to verify authentication requests. A trust path is a series of trust links from one domain to another, established for passing authentication requests. For example, in Figure 4.8, if a user in Domain M requests access to a resource located in Domain P, the domain controller in Domain M must follow the trust path to communicate with the domain controller in Domain P to verify the authentication request.
Figure 4.8 Trust paths
The communication process follows these steps:
Although this process eventually results in the user being able to access the resource, the process takes time and affects query response performance. In addition, each time clients are referred to another domain controller, the chances of a failure or of encountering a slow link are increased.
Windows 2000 provides a means for improving query response performance with cross-link trusts. A cross-link trust is a two-way transitive trust that you explicitly create between two Windows 2000 domains that are logically distant from each other in a forest or tree hierarchy in order to optimize the interdomain authentication process. Cross-link trusts are also known as shortcut trusts. Cross-link trusts can be created only between Windows 2000 domains in the same forest. Figure 4.9 illustrates a cross-link trust created to shorten the trust path and improve query response performance between Domain M and Domain P described earlier.
Figure 4.9 Cross-link trust
Because cross-link trusts must be explicitly set up, you must determine whether there is enough authentication traffic between the distant domains to warrant the administrative effort.
By defining a hierarchy of domains for your organization, you provide a structure for naming domains, which we will explore in Lesson 4, "Naming Domains." To define a domain hierarchy, you must complete the following tasks:
To define your organization's domain hierarchy, you must first consult the following documents compiled earlier by your design team:
Blank copies of the worksheets are located on the Supplemental Course Materials CD-ROM (\chapt02\worksheets). Completed examples of the worksheets are located in Chapter 2, "Introduction to Designing a Directory Services Infrastructure."
In addition to assessing the data compiled in these documents, it is imperative that you also assess changes currently planned to information flow or network architecture to address growth, flexibility, and the ideal design specifications of the organization.
To determine a domain hierarchy, you must analyze information about the organization to determine the number of domain trees, designate tree root domains, arrange the subdomain hierarchy, and plan any cross-link trusts.
Determining the Number of Domain Trees
Recall that a tree is a grouping or hierarchical arrangement of one or more Windows 2000 domains with contiguous names that you create by adding one or more child domains to an existing parent domain. A forest can have one or more trees. However, one tree per forest is considered ideal because it requires fewer administrative activities. Although the recommended number of trees in a forest is one, you may need to define more than one domain if your organization has more than one DNS name.
Implications of Using Multiple Trees
Using multiple trees increases administrative costs. When determining whether to define multiple domains, keep the following items in mind:
Designating Tree Root Domains
Once you've determined the number of trees in each forest for your organization, you should determine which domain will serve as the tree root domain for each tree. The tree root domain is the highest-level domain in the tree, under which its child and grandchild domains are arranged. Typically, the domain you select should be the one that is most critical to the operation of the tree. A tree root domain can also be the forest root domain, as shown in Figure 4.10.
Figure 4.10 Tree and forest root domains
Arranging the Subdomain Hierarchy
After you've determined the number of domain trees and designated the root domain for each tree, the next step in defining a domain hierarchy is to arrange the remaining subdomains in a hierarchy under the root domains. Recall that domains need not be arranged based on administrative structure. You will still be able to represent your administrative structure when you set up OUs and groups, as discussed in Chapter 5, "Creating an Organizational Unit Plan." More importantly, you should arrange domains in a manner that takes advantage of the implicit, two-way transitive trust between parent and child domains. Finally, you should keep your domain tree hierarchy shallow. One level of domains per tree is ideal; for best performance you should restrict the levels to three or four.
Planning Cross-Link Trusts
The final step in defining a domain hierarchy is to determine which domains need to be linked by cross-link trusts. Use the Information Flow Worksheet to determine which domains need access to resources in other domains. If these domains have not already been placed near each other in the hierarchy, you can optimize trust relationships by planning cross-link trusts.
To define a domain hierarchy
Pacific Musical Instruments currently uses only one registered DNS name, pac-100times.com. The organization does not anticipate needing any other DNS names, so it will have only one tree in its Active Directory infrastructure. Because Pacific Musical Instruments has only one tree, the forest root domain will also serve as the tree root domain.
The finance, human resources, and sales departments at each regional office all require access to resources stored at the Honolulu headquarters. Although each regional office must then go through the root domain to access resources at the Honolulu headquarters, there is no need to use cross-link trusts in this scenario, because the domains are close to each other in the hierarchy. The domain hierarchy diagram for Pacific Musical Instruments is shown in Figure 4.11.
Figure 4.11 Domain hierarchy diagram for Pacific Musical Instruments
In this lesson you learned how to define a domain hierarchy for each forest in an organization by assessing needs, determining the number of domain trees, designating tree root domains, arranging the subdomain hierarchy on a diagram, and planning cross-link trusts.
You also learned that the recommended number of trees in a forest is one; however, the number of DNS names employed by your organization determines the number of domain trees needed for the domain hierarchy. The tree root domain is the highest-level domain in the tree, under which its child and grandchild domains are arranged. A tree root domain can also be the forest root domain. After determining the number of trees and the tree root domains, you should arrange the subdomains in a manner that takes advantage of the implicit, two-way transitive trust between parent and child domains. To optimize the inter-domain authentication process, you can explicitly create cross-link trusts, which are two-way transitive trusts between two Windows 2000 domains that are logically distant from each other in a forest or tree hierarchy. A shallow domain tree hierarchy is recommended, with no more than three or four levels of domains.