- Domain Design Overview
- Choosing Your Domain Namespace
- New Domain Design Features in Windows .NET Server 2003
- Choosing Your Domain Structure
- Single Domain Model
- Multiple Subdomain Model
- Multiple Trees in a Single Forest Model
- Federated Forests Design Model
- Peer-Root Domain Model
- Placeholder Domain Model
- Special-Purpose Domains
- Renaming an Active Directory Domain
- Summary
- Best Practices
This chapter is from the book
This chapter is from the book
This chapter is from the book
Multiple Trees in a Single Forest Model
Let's say that your organization would like to look at Active Directory and wants to use an external namespace for your design. However, your environment currently uses multiple DNS namespaces and needs to integrate them into the same design. Contrary to popular misconception, integration of these namespaces into a single AD forest can be done through the use of multiple trees that exist in one forest. One of the most misunderstood characteristics of Active Directory is the difference between a contiguous forest and a contiguous DNS namespace. Many people do not realize that multiple DNS namespaces can be integrated into a single Active Directory forest as separate trees in the forest. For example, Figure 5.6 shows how Microsoft could theoretically organize several Active Directory domains that share the same forest but reside in different DNS namespaces.
){kind=small}
Figure
5.6 Sample Active Directory forest with multiple unique trees within the
same forest.
Only one domain in this design is the forest root, in this case microsoft.com, and only this domain controls access to the forest schema. All other domains, including subdomains of microsoft.com and the other domains that occupy different DNS structures, are members of the same forest. All trust relationships between the domains are transitive, and trusts flow from one domain to another.
When to Choose a Multiple Tree Domain Model
If your organization currently operates multiple units under separate DNS namespaces, one option may be to consider a design such as this one. It is important to understand, however, that simply using multiple DNS namespaces does not automatically qualify you as a candidate for this domain design. For example, you could own five separate DNS namespaces and instead decide to create an Active Directory structure based on a new namespace that is contiguous throughout your organization. Consolidating your Active Directory under this single domain could simplify the logical structure of your environment while keeping your DNS namespaces separate from Active Directory.
If your organization makes extensive use of its separate namespaces, you may want to consider a design like this. Each domain tree in the forest can then maintain a certain degree of autonomy, both perceived and real. Often, this type of design will seek to satisfy even the most paranoid of branch office administrators who demand complete control over their entire IT structure.
Real-World Design Example
To gain a greater understanding of the times an organization might use this particular design model, let's look at the following AD structure. City A is a local county governmental organization with a loose-knit network of semi-independent city offices such as the police and fire departments that are spread out around the city. Each department currently uses a DNS namespace for name resolution to all hosts and user accounts local to itself, which provides different e-mail addresses for users located in the fire department, police department, and other branches. The following namespaces are used within the city's infrastructure:
citya.org
firedeptcitya.org
policeofcitya.org
cityalibrary.org
The decision was made to merge the existing network environments into a single Active Directory forest that will accommodate the existing departmental namespaces but maintain a common schema and forest root. To accomplish this, Active Directory was established with citya.org as the namespace for the root domain. The additional domains were added to the forest as separate trees but with a shared schema, as shown in Figure 5.7.
){kind=small}
Figure
5.7 Single Active Directory forest with separate directory trees for departments.
The individual departments were able to maintain control over their individual security and are disallowed from making changes in domains outside their control. The common forest schema and global catalog helped to increase collaboration between the varying organizations and allow for a certain amount of central administration.
This type of domain design is logically a bit messier but technically carries the same functionality as any other single forest design model. All the domains are set up with two-way transitive trusts to the root domain and share a common schema and global catalog. The difference lies in the fact that they all utilize separate DNS namespaces, a fact that must also be reflected in the zones that exist on your DNS server.