Active Directory Forest Design Principles
This blog entry was written 16 July 2006. Since much of it is still relevant in today’s Windows Server 2008 R2 Active Directory, I took the liberty of reposting it in my new techblog. – Jay Paloma
Since the forest is a new concept in Active Directory, a lot of organizations do not consider its importance in the scheme of things. The Active Directory Forest is the boundary of the Active Directory Schema and Configuration partitions, as well as the boundary of the Global Catalog. Any bad decisions with regards to the Active Directory forest will have a big implication on Active Directory.
The considerations needed to cover in the Forest Design exercise are:
Forest model, whether to use a single or multiple forest architecture.
The use of the Placholder Forest Root Domain.
How the Forest Root Domain Administrator is to be used.
Single or Multiple Forests
A classic example of the necessity of using a single Forest is when Microsoft Exchange Server 2000 or 2003 is in the picture. The Exchange Global Address List (GAL) is based on the Global Catalog. Attributes relating to the Exchange infrastructure reside in the Configuration partition, and as such, new attributes relating to Exchange infrastructure are added in the Active Directory Schema.
In Microsoft Exchange, there’s no if’s or but’s about it: One Exchange Organization : One Active Directory Forest.
Imagine: implementing a multiple-forest design and one day being compelled to integrate these multiple forests into a single Exchange Server 2003 Global Address List. A double whammy of work — additional work to create multiple forests, and additional work to integrate these multiple forests!
If it is a must that the organization only has a singular Schema, Configuration or Global Catalog, then that organization has no choice by to have a single Active Directory Forest.
When there is supposed to be a clear delineation between Configuration, Schema and Global Catalog of one organization against another, implement multiple forests. An example of this when Microsoft Exchange Server is being evaluated by the organization. Installing Exchange makes around 2,500 new attributes to the Active Directory Schema, and since the product is still under evaluation and the organization may or may not implement Microsoft Exchange, then it would not be a wise decision to make permanent changes to the Active Directory Schema.
In addition, it is also wise to implement multiple forests when security considerations dictate the isolation of the Schema, Configuration and most especially the Global Catalog. In a military scenario, it would not be advisable to carry around a mobile Exchange Server whose Domain Controller contains the Global Catalog and in no small matter the Global Address List for the entire military organization intact. In these cases, it may be more prudent that separate forests are implemented on each mobile pack so if ever the pack was compromised, then the only information available is with regards to recipients in that pack, and not the entire military organization.
Placeholder Forest Root Domain
Whether Single or Multiple Forests, we also need to make a decision as to the domain model for each Forest. Some organizations prefer a forest that is oblivious to corporate decisions on names. The solution to this is to implement a Placeholder Forest Root Domain. In simple terms, the Placeholder Forest Root Domain is an unused and insignificantly-named Forest Root Domain whose role is just as its name implies: a placeholder. The working domain is on another tree in the forest. This ensures that should there be a rename of the organization, then user and computer objects would just need to be moved from one domain to another bearing the new name without removing them from the forest.
In spite of the fact that it is possible to rename domains in Windows Server 2003, some organizations still opt to use the Placholder Forest Root Domain since the domain rename operation is thorough, requiring a detailed understanding of the operation, and is not a routine operation.
The characteristics of the Placeholder Forest Root Domain are as follows
It is the Forest Root domain. This domain should not have subdomains in a tree relationship.
It does not bear the company name. Its name should be as insignificant as possible. Some companies use zFORESTROOT.LOCAL as the name. Beginning the name with a Z displays this domain name last in the GINA domain drop down list when users log on.
Users and computers are NOT placed in this domain.
If this model is not adapted, and the company renames, most probably the working domain bears the company name and it is the Forest Root domain, in which case we need to migrate users from one domain to another domain bearing the new name of the company. Unfortunately this domain should be in another forest, in which case functinality of Microsoft Exchange is affected.
If this model is adapted, then yes we still need to move users to the new domain, however this new domain is still a member of the old forest, therefore Exchange is still functional, given that we perform the necessary preps for Exchange.
Advantages of using the Placholder Forest Root
The Active Directory Forest is name-proof
The domain controllers (yes, plural — see Disadvantages below) for the placholder forestroot domain may also act as the forest Operations Masters roles Schema Master and Domain Naming Master.
The possible top-level time servers for the forest is clear: by default it is the PDC Emulator of the Forest Root Domain. As such, these domain controllers can be given access to NTP in the firewall. In addition, other domains’ DNS servers can be configured to use the forest root DNS servers as forwarders. Internet access (i.e., NTP and DNS Query) from domain controllers can now be limited to the forest root domain controllers, assuming that proper patch management measures like WSUS are in place.
The Schema Admins and Enterprise Admins groups, only found in the Forest Root domain, are isolated from the working domains and from the prying eyes of downlevel administrators.
Disadvantages of using the Placholder Forest Root
The usage of at least two domain controllers (for availability) virtually doing nothing. Note that if this domain goes down, the entire forest is kaput!
Possible “Layer 8” (Political) issues as to the management of the Forest Root Domain, specifically the knowledge of its Administrator password. If politics without technology principles plays a role in the Forest design, then it is ominous to a long-term Active Directory failure.
The Forest Root Domain Administrator
Whatever the design of the Active Directory forest will be, it is important to consider the role of the Forest Root Domain Adminisistrator. This is the default Administrator account for the Forest Root Domain. At the same time, this account is also a member of the Schema Admins and the Enterprise Admins groups. Meanwhile, in a native mode scenario, the Enterprise Admins Universal Group is a member of all Administrators Domain Local Groups in the entire forest, making this account an effective Administrator for all domains in the Forest.
In a centralized organization, the Forest Root Domain Administrator is not really an issue. However, in decentralized organizations, especially those on Exchange Server 2000 or 2003, this consideration is a very important one because of its security implications and the possible impact on Exchange Server.
To aggravate the situation, “Layer 8” comes into the picture. Since Forest design involves the entire organization and in a decentralized environment, all IT decision makers and their technical advisers may be present in the design exercise, and there might be some who may have the political clout to monopolize the decisions based on what is beneficial to his/her sub-organization, but not necessarily the rest of the organization.
Some effective measures to properly manage the Forest Root Domain admin is as follows:
Implement two-factor authentication for the Forest Root Domain Administrator, with the Smart Card in possession by possibly the CIO. It is best that the bearer of the smart card does not have knowledge of the password to ensure role separation. This smart card should be kept away in a vault. Since the smart card and the password is borne by at least two separate entities, these two are required to be present during a logon of the said account. On the other hand, any unauthorized logon is the result of collusion between these two entities.
The password for this account should be non-memorizable, long, complex, written and signed off by all appropriate (IT heads of sub-orgs), highly trusted personnel. This paper is to be sealed in another vault separate from the smart card.
These personnel should test logging on to the Forest Root Domain administrator account to verify that the written password is indeed the Forest Root Domain administrator password. A periodic testing of the logon procedures is important to ensure that the account has not been compromised.
The signoff document should include guidelines on the usage of the Forest Root Admin account, (from where, what nature, what tasks, witnesses, documented requests, etc.) with harsh administrative penalties in case of violation.
Designing the Active Directory Forest
Always start with a single Forest. Then using the conditions mentioned above, make decisions on whether the organization needs to adapt a multiple forest architecture. When the organization makes a decision on the multiple forest design, then make sure all the possible risks had been mitigated and understood by all parties. Since forest design involves the entire organization, it will be prudent to include all IT decision makers for each sub-organization in this design exercise.
Then decide on whether to implement a placholder forest root domain for the organization. Also make it clear about the implications of the Forest Root Domain Administrator and how its password is to be maintained.
Finally, decide on how to handle the Forest Root Domain Administrator
My Tips and Experiences on Forest Design
It is a BAD decision to implement multiple forests based only on the Forest Root Domain Administrator implications mentioned above. Consider all possible decision factors, not just on one. Some organizations I’ve worked with spent more money in consolidating a multiple-forest environment, wherein it would not cost them a single cent to properly make decisions in the handling of the Forest Root Domain Administrator.
Make design decisions based on the pros and cons of each design consideration, and don’t fall into the Layer 8 trap. Each design element should be backed up with corresponding merits for that decision, as well as risk identification and mitigation if ever risks are involved in each design element. This actually disempowers the Layer 8 entity, since any decision is to be backed up by technical merits as well as risk identification and mitigation, not just political clout.