Political Forest and Domain Design
In my work with a large number of federated customers, the unavoidable component of Active Directory design is the age-old question of "How many forests do I need?"
This is simple to define, but challenging to discuss in the board room. There are three types of forests: enterprise forests, resource forests, and isolated forests. Every organization should strive towards a single enterprise forest. The reason is simple; enterprise applications (like Exchange 2000+) are designed and built on Active Directory and the forest is the AD boundary. Therefore, multiple forests equals multiple Exchange organizations and adds a whole lot of complexity if a political organization wants to share Exchange-like functionality across multiple forests.
The resource forest is analogous to the resource domain in Windows NT 4.0. It does not contain regular user accounts or enterprise-wide applications. Instead, it contains resources that require a different level of trust from the remainder of the enterprise. HR applications are generally the best example. HR may desire that enterprise admins have only basic user roles in their applications, but cannot achieve that unless the EA account passes over a limited trust arrangement. Resource forests generally grant permissions to the user accounts in a trusted forest, rather than create new user objects, thereby providing for the security requirements without breaking the single sign-on model.
The isolated forest is one which does not contain enterprise applications or any trusts to the enterprise forest. Every user account in the isolated forest requires a separate logon and, often times, may not be directly accessible from the enterprise forest at the lower layers of the OSI model. The isolated forest is rare and reserved for the most security-critical of applications.
So the answer to the question of how many forests is one. One enterprise forest is all any customer should need. Directory information is generally not top-secret stuff (at least, we shouldn't be storing secret stuff in AD). But that does not mean that any organization requires only one forest.
Resource forests may be required anytime security needs dictate (see Design Considerations for Delegation of Administration in Active Directory for more information). However, the following decision tree should be followed whenever a new forest is being considered as most customers base their desires for a separate forest on the need for autonomy versus a need for true service or data isolation. Given the complexity and cost of multiple forests, they should always be a last resort.
My customers are great about understanding the differences and requirements for distinguishing between enterprise and resource forests, but when we get into the details of the enterprise forest, things begin to get cloudy. I blame the gray clouds on "domain admin envy syndrome." No one (departmentally)wants to lose their domain admin privileges, so domains ultimately are created to accomplish what could be done with Organizational Units.
Until today, though I've harped on this topic for some time, I didn't have a clear picture in my mind that allowed me to provide a solid technical explanation of why multiple domains under multiple political administrations was not the best solution. I had always said, "everyone needs to trust anyone who could become a domain admin" which is certainly not always true in a federated infrastructure. However, the reason that federations can create problems lies in how enterprise applications (built for AD) are designed and behave. I will use Exchange 2003 as the example.
Enterprise Applications, and Exchange in particular, must be defined for purposes of my argument. Enterprise applications are those that build on or leverage the information already present in Active Directory. To properly function, therefore, an enterprise application must write to all naming contexts in AD (schema, config and every domain NC). In a single domain forest, or even a multiple domain forest under centralized control, one group owns access to these containers. In a multiple domain model under multiple administrations, every domain has a different group of domain admins with permissions to write data to the configuration naming context. The choices that these administrators make may not always be in the best interest of the other domain admins of the federation.
Domain naming contexts are a different story, because domain admins can generally only make changes to their own domain, with little impact to the other members of the federation (although, I suppose, there are exceptions). However, the need for enterprise applications to change information in the configuration naming context is a whole different ballgame. This doesn't mean that federations can't work, but it does reinforce the notion that all players MUST trust the domain admins of all other players, because any one of them could make changes that affect everyone.
Fortunately, in the case of Exchange, this very problem has been somewhat taken into consideration in the design of the product. Generally speaking, Exchange allows additional objects to be created in the Config NC (under the Exchange org in ADSIEdit), but not destroyed. So while it wouldn't prevent someone in another department from creating a new storage group, one could see the creator owner property of the storage group and take corrective action.
Exchange locks down some of the delegation issues that federations may otherwise experience by developing its own permissions and admin model (done through the Exchange roles). This ensures that members of one department are delegated access only to the servers and resources in their administrative group.
Exchange 2003 further locks down this issue by creating a special group, Exchange Domain Servers, to which it grants the role of making some of the changes described above. Only the domain admins can add members to this group, and as a matter of policy, the group should only ever contain server objects. Although some folks might consider this group a security risk (since it has some level of permissions in every domain and across the entire Exchange Org), the permissions (ACLs) granted to this group are so limited (least privileged) as to prevent the possibility of any serious threat. Minor annoyances between administrators, however, are still possible, but only if one administration breaks the policies in place.
The important part of this whole discussion, however, is that part of your AD Design is dependent on the enterprise applications you intend to deploy. In the case of Exchange (the most common driver), most departmental participants are safe from major issues, but the same may not be true of all enterprise apps.
When thinking about your forest design, particularly if you know and live in a federated model, consider your security and political needs. Fact is, true hardened security in a single forest can only be achieved with one trusted group ruling all. Peer-based domain models, while politically appealing, are not hardened security boundaries and therefore require the same level of trust across dozens of individuals that might be otherwise easy to achieve when asked of a few. Technology is only one part of security. People generally represent the weakest link. If the federated domain, single forest model sounds appealing to you, please take the time to do your homework and ensure that personnel policies are in place from all parties involved to ensure that trust can flow among every domain in the forest.