Why Organization adopt implementing multi-domain Active Directory environments?

Implementing multi-domain Active Directory environments or multi-domain forests in an organization is adopted just because of the following scenarios


Each Windows Server 2012 R2 functional level domain supports the creation of around 2.15 billion relative identifiers (RIDs) and domain controller is able to create around 2.15 billion objects. These numbers are theoretical approximations and these limits haven’t been reached in a real world production Active Directory environments. When you consider these figures you’ll understand that the primary reason for creating a multi-domain Active Directory forest won’t be because the current domain can’t support the creation of any more objects.
While considerations around replication are one reason, primarily organizations implement multi-domain forests because of issues beyond the strictly technical, including, but not limited to, the following conditions:

Historical naming structure

When an organization have inherited a domain structure from their parent or sister organization which implemented Active Directory first. It might be that there are multiple domains in an environment where Windows Server 2012 R2 is used to host domain controllers because no one got around to altering the structure that was in place when Windows 2000 domain controllers were first introduced.

Organizational and political reasons

Some organizations are conglomerates including several separate companies which share a single administrative and management group. For example, a university in a Commonwealth country might use a structure where each faculty has a separate domain that is a member of the same forest, with users in the Faculty of Arts signing on to the Arts domain and users in the Faculty of Science signing on to the Science domain.

Security considerations

Domains allow the implementation of authentication and authorization boundaries, allowing one set of administrators to manage users and computers from one part of the organization without allowing those same administrators to manage users and computers from another part of the organization. While you can implement a solution to accomplish the same objectives using delegation of privileges, you may have to comply with legislation that is worded in such a way that it’s easier to meet those compliance obligations by segmenting users and computers across separate domains in the same forest.

Even though a single domain forest might appear to be the most appropriate technical solution, it might not be the most appropriate organizational or political solution. Although questions around organizational politics aren’t likely to turn up on the 70-412 exam, they will arise when you go to apply the knowledge tested on the exam in the real world.

When considering the creation of a multi-domain forest, you have the choice between using one or more domain trees. A domain tree is a collection of domains that share a common root domain name in a parent/child relationship. For example, adatum.com, queensland. adatum.com, victoria.adatum.com, melbourne.victoria.adatum.com, and tasmania.adatum.
com could all be domains that are members of the same domain tree. All domains in this tree share the adatum.com suffix. The parent/child relationship between domains in this tree is indicated by the addition to the domain name namespace. In this example, queensland.adatum.com, victoria.adatum.com, and tasmania.adatum.com are all child domains of the adatum.com domain and the melbourne.victoria.adatum.com domain is a child domain of the victoria.adatum.com domain. The depth of the any one branch of a domain tree is limited by a domain having fully qualified domain name length, including periods, of 64 characters.

An Active Directory forest supports multiple domain trees, meaning that you could have Adatum.com as the root domain and a domain tree under Adatum.com, but that you could also have additional domain trees that use separate name spaces that also are child domains of Adatum.com. For example, it’s possible to have contoso.com and fabrikam.com as child domains of Adatum.com. You might use this configuration for conglomerates, where multiple separate public facing business entities are actually all managed centrally.

The advantage of being able to support non-continuous namespaces in a single forest is that all domains in a forest automatically trust one another. This means that in the example where contoso.com and fabrikam.com are child domains of adatum.com, you can assign permissions to objects in the Adatum.com and fabrikam.com domains to a user who signs on to the contoso.com domain.