Design Overview
The best practice recommendations regarding Active Directory Forest and Domain design have changed since Windows 2000 was released. The current direction is based primarily upon differences in security between domains and forests, but simplicity and economics have gained prominence as well.
In Windows 2000, the security boundary was believed to be at the domain level, hence the recommendation for the empty forest root domain and the child accounts domain model. However, this was proven to be incorrect as rogue administrators in the child domain found that they could elevate their privileges and gain access to the forest root domain. When Windows 2003 was released, the single domain forest became the best practice recommendation. Microsoft correctly stated that the security boundary was at the forest level, not the domain level and this continues today with Windows 2008.
Design Options
The primary Microsoft recommendation in forest and domain design is to simplify where possible. Let's consider a few design options. Looking at the forest and domain options in Figure 1:
- Each box is a forest.
- Each triangle is a domain.
Figure 1 – Forest and Doman Design Options
Design Options Detailed
Option 1
This is the Windows 2000 era "Empty Root" design based upon the domain boundary protection. It was later determined that AD domains do not provide the desired security boundary. Therefore, the empty root design is difficult to justify from a security standpoint.
Option 2
This is the currently recommended Best Practice forest design, a Single Domain Forest. In a scenario where all users, computers and resources are located in a single site or can be contained within a single domain, it's the recommended design.
Option 3
This design puts control of the forest root into the realm of a specific country or region and is not recommended. If a regional design is needed, then Option 4 is considered to be a better design.
Option 4
If a regional domain model is required, the original empty root design can be considered. Option 4 depicts two regional domains and a resource domain. In this design, two-way transitive trusts are automatically created between all domains. Therefore, each child domain automatically trusts all other child domains. For security purposes, this may not be the desired end state (since the Domain is not a security boundary). If the organization includes groups that require data isolation or service isolation from other groups in the organization, separate forests for these groups must be created. Domains do not provide secure data or service isolation.
Historically, the two primary reasons for a multi-domain design were to provide differing password policies or to accommodate replication requirements due to poor WAN links with high latency between regional locations.
In Windows Server 2008 AD DS, fine-grained password policies are now available to specify multiple password policies within a single domain, further diminishing the need for the multi-domain design model. WAN performance has also improved. Therefore, justifying the need for a multi-domain design is questionable.
Also note that Exchange Server 2007 does not allow mail-enabled global security groups. When a company has more than one domain AND Exchange Server 2003, they can and often do make global groups mail-enabled. When transitioning from E2K3 to E2K7, all mail-enabled security groups will need to be converted to mail-enabled universal groups. This is a time intensive task, which is further complicated within a multi-domain implementation.
Option 5
A multi-forest design provides the security boundaries when required in the context of data autonomy, data isolation or service isolation. This is often recommended for compliance purposes (HIPAA, FIRPA, PIPA, etc.).
Shared resources that must meet compliance requirements can be deployed using a resource forest model with dedicated, secure networks and perimeter protection.
Non-shared resources that must meet compliance requirements can be deployed using a multi-forest model with dedicated, secure networks and perimeter protection.
Forest Design Recommendation
In a scenario in which all users, computers and resources reside in a single location, Option 2, the single domain forest is the recommended design model. A single domain forest can also accommodate multiple locations across an enterprise that have good WAN connectivity and should always be the first consideration.
If requirements specifically mandate that multiple domains be implemented, then Option 4, the regional domain model can be considered. As noted above, this design model is becoming more difficult to justify as Option 2 can provide multiple security policies within a single domain and easily accommodates multiple locations.
Option 5 is the recommended design model when it's necessary to maintain data isolation and/or service isolation in a secure environment to meet compliance requirements.
Note:
A special thanks to Forrest McDuffie and Mark Myers for their input to this article.
Additional information regarding the forest and domain design process can be found on the Microsoft TechNet Library for Windows Server 2008 site. http://technet.microsoft.com/en-us/library/cc706994.aspx
The information within the technical library site is considered Best Practice.
David Fedko
Senior Consultant
Project Leadership Associates
