For
various reasons, organizations might need to add more than one domain
to their environment but preserve the functionality that is inherent in a
single forest. When this occurs, the addition of one or multiple
domains into the forest is warranted. Domain addition should not be
taken lightly, however, and proper consideration must be given to the
particular characteristics of multiple domain models.
By
default, two-way transitive trusts exist between subdomains and domains
in AD DS. Bear in mind, however, that this does not mean that resource
access is automatically granted to members of other domains. A user in
subdomain B is not automatically granted any rights in domain A; the
rights need to be explicitly defined through the use of groups.
Understanding this concept will help to determine the logistics of
domain addition.
Choosing When to Add Additional Domains
As previously mentioned,
it is advisable to begin your Windows Server 2008 R2 AD DS design with a
single domain and then add domains only when absolutely necessary.
Adding child domains to an existing domain structure might become
necessary if the following traits exist within an infrastructure:
Decentralized administration—
If different branches of an organization generally manage their own IT
structure and there are no future plans to consolidate them into a
centralized model, multiple interconnected domains might be ideal. Each
domain acts as a security boundary for most types of activity and can be
set up to disallow administration from escaping the boundaries of
domains. This approach, however, exposes many of the limitations
associated with a multiple domain environment. In other words, it is
better to try to centralize administration before deploying AD DS
because you will gain more of AD’s advantages. It is also much better to organize administration along organizational unit boundaries than by domains, so consider this option first.
Geographic limitations—
If extremely slow or unreliable links or great geographical distances
separate different parts of your company, it might be wise to segment
the user population into separate domains. This will help to limit
replication activity between domains and also make it easier to provide
support during business hours for distant time zones. Keep in mind that
slow links by themselves do not necessitate the creation of multiple
domains, as Windows Server 2008 R2 AD DS uses the concept of AD DS sites
to throttle replication across slow links. The main reason that might
exist for domain creation for geographical reasons is administrative
flexibility. In other words, if there is a problem with the network in
Japan, a Japanese administrator will have more power to administer the
Asia domain and will not need to call the North American administrator
in the middle of the night.
Unique DNS namespace considerations—
If two organizational entities want to use their Internet-registered
namespace for AD DS but use a common forest, such as hotmail.com or
microsoft.com, those domains must be added as separate domains.
Enhanced security concerns—
Depending on the needs of your organization, separating the schema
master role into a domain separate from your users might be applicable.
In this case, the single domain model would not be applicable, and a
model such as the peer-root or placeholder domain would be more
appropriate.
When contemplating
additional domains, remember the mantra, “Simplicity is best.” However,
if during the design process, the specific need arises to add domains,
proper design is still warranted, or your environment will run the risk
of becoming more inefficient than it could be.
Exploring a Multiple Domain Real-World Design Example
The following example
illustrates an organization that would have grounds to establish
multiple domains. CompanyB is an engineering company based in York,
Pennsylvania. Administration for all branch locations is currently
centralized in the home office, and OUs and group policies are used for
delegation of lower-level tasks. Recently, the company acquired two
separate companies named Subsidiary A and Subsidiary B; each contains
its own IT department and operates in separate geographical areas.
CompanyB decided to implement AD DS as part of a Windows Server 2008 R2
implementation and wanted to include the two acquired companies into a
single common forest.
Because each acquired
company possesses its own IT department and there was no agreement on
the ownership of the Domain Admins accounts, CompanyB decided to deploy
an AD DS structure with two subdomains for Subsidiary A and Subsidiary
B, as shown in Figure 1.
This
design model allowed for a certain degree of administrative freedom
with the newly acquired subsidiaries but also allowed for a common
forest and schema to be used and kept the domains within the same DNS
namespace.
This design model has
the particular advantage of being politically easier to implement than
consolidation of existing domains. Branch offices and subsidiary
companies can keep their own domain structure and security boundaries,
and their IT teams can retain a greater deal of administrative autonomy.
Be warned, however, that
consolidation of a larger number of domains into fewer domains is a key
feature of AD DS, so the addition of domains purely for political
reasons adds complexity and potentially unnecessary infrastructure. It
is, therefore, very important to consider the alternatives before
deciding on this design model.
