Let’s
say that your organization wants to look at AD DS 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 AD DS 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 AD DS forest as separate
trees in the forest. For example, Figure 1
shows how Microsoft could theoretically organize several AD DS domains
that share the same forest but reside in different DNS namespaces.
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.
Choosing When to Deploy a Multiple Tree Domain Model
If an organization
currently operates multiple units under separate DNS namespaces, one
option might 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 AD DS structure based on a new namespace that is contiguous
throughout your organization. Consolidating your AD DS under this
single domain could simplify the logical structure of your environment
while keeping your DNS namespaces separate from AD DS.
If your organization makes
extensive use of its separate namespaces, you might 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.
Examining a Multiple Tree Domain Real-World Design Example
To gain a greater
understanding of the times an organization might use this particular
design model, examine the following AD structure. CityA 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 email addresses for users located in
the fire department, police department, and other branches. The
following namespaces are used within the city’s infrastructure:
The
decision was made to merge the existing network environments into a
single AD DS forest that will accommodate the existing departmental
namespaces but maintain a common schema and forest root. To accomplish
this, AD DS was established with citya.gov
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 2.
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 in DNS.
