Empty Root place holder – Still a valid design choice?

 Empty Root

One of the questions as I am often asked is about having an empty place holder domain in the environment and whether one should still be deployed.When Active Directory was first released with Windows 2000, an empty root place holder domain was deemed best practice for a multitude of reasons.

 Enterprise/Domain segregation

The concept behind the empty root was simplistic, you have a root domain with all the forest wide security principals (Enterprise Admin’s, Schema Admin’s), plus other critical accounts and groups and then one of more child domains hosting user accounts, groups, computers etc. this principal was based on the initial concept that the security boundary was the domain, but it soon became apparent that this was in fact not true. The forest was the security boundary and not the domain.

Therefore regardless of your version of Windows Server, 2000, 2003 or 2008 security especially physical security is still a major consideration.

Kim Cameron has defined the 10 immutable laws of security
http://technet.microsoft.com/en-us/library/cc722487.aspx .

These I feel are the four that pertain the most.

Law #2: If a bad guy can alter the operating system on your computer, it’s not your computer anymore
Law #3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore
Law #6: A computer is only as secure as the administrator is trustworthy
Law #7: Encrypted data is only as secure as the decryption key

Most datacentre’s are secure entities but as the Active Directory becomes distributed to the branch offices, security may not be as secure and dependant upon your operating model the Domain Controller might not even be a dedicated server and perhaps just sat in the middle of the office. This branch office Domain Controller has the same information about all accounts as the highly secured Domain Controller in the datacentre.

If I have physical access to your Domain Controller the Administrator password can be reset with a reboot and a “Special CD”, dependant upon intent, the havoc caused could be fatal. Access can also be gained to any other domain in the forest including the empty root domain. I will not go into anymore detail here.

To mitigate the risk of physical security being compromised Microsoft introduced the Read Only Domain Controller (RODC), an RODC is a domain controller that by default does not store any passwords on it and only caches the passwords it is told to. It will also never cache administrative passwords.

Another consideration is Bitlocker on the Domain Controllers, a TPM 1.2 is required for an optimum configuration, but the keys to the encryption need to be managed, these can be stored in Active Directory, but they are stored in the Active Directory in clear text which is ACL’d.


In Windows 2000 Server and Windows Server 2003 if you wanted to natively deploy multiple password policies to users, a separate domain was needed. This was configured in the Domain Group Policy Object (GPO) and even though the password policy setting appeared in all GPO’s, if configured in any other GPO it would only affect the local machines password policy.

In Windows Server 2008 this is no longer an issue, as Fine Grained Password Policies (FGPP’s) have been implemented – thus removing the need for multiple domains. FGPP’s allow for multiple password polices to be applied on a single domain.

DNS Replication

In Windows 2000 Server, Active Directory integrated DNS Zones were replicated when the domain partition replicated, meaning that even if the Domain Controller was not a DNS Server it unnecessarily replicated and stored the DNS information. Windows Server 2003 rectified this by introducing application partitions, Windows Server 2003 now has two additional  partitions, a Forest DNS Zone and a Domain DNS Zone. These two partitions host either Forest or Domain DNS information but when replication is being calculated – unless the Domain Controller hosts the application partition – the information if not replicated to that Domain Controller or via that Domain Controller.


Since the early days of Active Directory, the concept of multiple domains based on regions has been implemented to reduce the amount of replication traffic, but since Windows Server 2003 introduced Linked Value Replication (LVR) and new compression algorithms, replication is perhaps no longer a major consideration when considering a multiple domain model.  


An empty forest root, is an expense that may not be necessary and ignoring the initial physical costs – it will still need to be housed, powered, managed, patched, backed up and monitored. In reality as the forest root is not used daily it is often forgotten about and not maintained – if the empty forest root were to have a catastrophic failure and the backups were not valid – the entire forest would have to be rebuilt. Food for thought alone!

Single domain or root and child domain(s).

Microsoft’s official stance is start with a single domain and implement new domains based on your own requirements as necessary, I can find nowhere an official statement stating the fact that the empty root domain is no longer valid; but it is widely accepted in Active Directory circles that having an empty forest root is no longer best practice – this does not mean it is wrong to implement an empty forest root – it just means that it is no longer best practice.

5 thoughts on “Empty Root place holder – Still a valid design choice?

  1. If a company with a forest root desired to remove it, how would they go about this without causing problems to the domain or domains under it?

    1. Alas, there are only two options with slight variations but in very simplistic terms.

      Using a tool such as ADMT you would need to perform an intra-forest migration and migrate all resources from the child domain(s) to the forest root or create a new single domain forest and migrate your resources into the new forest as an inter-forest migration (or if the forest is a mess a clean implementation).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.