When to Use Multiple Domains in a Single Tree

Identifying when to use multiple domains in a single tree, rather than multiple OUs in a single domain, is one of the hardest design decisions. Multiple domains in a tree share many of the same attributes that are shared between multiple OUs in a single domain. There is a shared Active Directory schema, security context, and namespace. So, why would you decide to implement multiple domains instead of implementing multiple OUs in a single domain? To make that decision, it is important to understand the characteristics of a multi-domain tree.

Schema

Multiple domains in a tree share a common schema. This means that the changes to the schema for the Active Directory database are written to the schema operations master and then replicated to other Domain Controllers (DCs) in the tree, as shown in Figure 20.3. By default, the schema operations master is the first DC in the Forest and the default schema is loaded on that DC when Windows 2000 is loaded for the first time. If changes are made to the schema on the schema operations master, they are replicated to every DC. Consequently, schema issues should not drive the decision process for selecting when to use multiple domains within an organization.

Figure 20.3. All domains in a tree share a common Active Directory schema.


Namespace

Just as they share a common schema, all domains in a tree share a common namespace. If the root domain for an organization is wadeware.net, then all child domains are a subset namespace of wadeware.net. Every child domain has exactly one parent domain. It is possible for a parent domain to have multiple child domains associated with it. Each level of the hierarchy is directly related in terms of namespace to the hierarchical level directly above and directly below. For example, below the root domain of wadeware.net there might be a child domain named northamerica. The namespace for this domain would be derived from the relationship with the domain above it. As such, the namespace for the domain associated with North America would be northamerica.wadeware.net.

This hierarchical relationship in the namespace is based upon the hierarchical relationship in the DNS protocol standard. This is the relationship that one DNS domain has with another, whether it is based on DNS supported in UNIX, on Windows NT, or on Windows 2000.

Business requirements for a hierarchical namespace in an organization might be a reason to implement a multi-domain tree. A large organization might require a multi-layered namespace that identifies attributes relative to the business model or business configuration of the company. Wadeware might need to have a namespace associated with business in North America and another namespace associated with business in the Middle East. This would require multiple domains in a tree and the namespaces would be northamerica.wadeware.net and middleeast.wadeware.net.

Security

All domains in a tree automatically share security trusts based on the Kerberos security protocol. In addition, they also share automatic transitive trusts with all other domains in the tree. This means that all users in a tree can access resources in all the other domains in the tree; as long as the proper access control lists (ACLs) have been set on the resources. The transitive trust is a two-way, secure relationship that exists between every child domain in the tree and their parent domain, as shown in Figure 20.4. This trust is established automatically when the domain is added to the tree. Transitive trust means that if Domain A trusts Domain B and Domain B trusts Domain C, then Domain A trust Domain C by way of the transitive trust of Domain B.

Figure 20.4. Transitive trusts between child domains and the parent domain.


Although every domain has an automatic transitive trust relationship when the domain is first created, it is also possible establish cross-link trusts between individual domains in the tree to improve the authentication performance. It is also possible to isolate a domain in the tree. Consequently, this is another significant reason why a multiple domain scenario might be appropriate versus a single domain scenario. It might be necessary to segment the administration of resources and users in a domain from users in other domains in the tree. This is something that is much easier to accomplish if the users and resources are segmented in to multiple domains rather than in multiple OUs within a single domain.

Replication Traffic

Replication traffic between DCs in a domain can also be a significant reason to consider a multi-domain tree. In a single domain, all changes made to Active Directory domain, including changes to all objects and properties, are replicated between DCs in that domain. This replication can be throttled and managed to a certain degree by implementing site architecture that overlays the domain structure. (See Chapter 10, "The Physical Topology: Sites and Replication," for a discussion on designing a site architecture.) However, all changes made to Active Directory data must still be replicated to all DCs.

In the case of multiple domains in a single tree, the only changes replicated between domains are changes to the GC server, configuration information, and modifications to the schema. If the Active Directory environment contains an infrastructure spread across multiple slow-speed WAN connections, a multiple domain tree should be considered.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.119.192.55