In Through the Back Door

A routine audit of Active Directory permissions can expose this example back-ended breach.

• By Bill Boswell
• 03/09/2004

Here's my question: Even with an empty or dedicated forest root, do all domain controllers in the forest have the same (Read/Write) copy of the Configuration naming context and a (Read) copy of the Schema naming context? If so, can they use ADSIEdit to modify those naming contexts and, in turn, have them replicated to all subdomains and back to the empty forest root?

Same question phrased differently: What are the implications of a local Domain Administrator in a subdomain using ADSIEdit to modify the Configuration and Schema naming contexts within their own subdomain? Does that affect the naming contexts in the empty/dedicated forest root, or does having an empty/dedicated forest root prevent this from happening?

I would really appreciate your response on this matter, as I have read and heard conflicting answers to this question and about the true security of using an empty/dedicated forest root.

Thanks you for your time and assistance in this matter.
—Don

Don: Just a quick review for anyone reading the column who isn't familiar with Active Directory.

In LDAP, a "naming context" forms a separate replication unit. The X.500 term for naming context is "partition." In Active Directory, each domain forms a discrete naming context. A domain controller hosts a full, read-write replica of its own domain naming context.

The Active Directory information base for a forest contains two other naming
contexts that hold objects that support forest-wide operations: Configuration and Schema. The forest root domain (first domain in the forest) roots the LDAP namespace for these forest-wide naming contexts. For example, if the forest root domain were company.com, then the Configuration naming context would have the distinguished name cn=Configuration, dc=Company, dc=com and the Schema naming context would have the distinguished name cn=Schema, cn=Configuration, dc=Company, dc=com.

In addition to these three naming contexts, Windows Server 2003 uses two additional Application naming contexts to store DNS records. Each domain has a separate DomainDNSZones naming context and the forest has a ForestDNSZones naming context.

Each domain controller in the forest hosts a read-write replica of its own Domain naming context, the Configuration naming context, and the Schema naming context. (Only the Schema Master is permitted to actually write to the Schema naming context, though.) In Windows Server 2003, if a domain controller is also a DNS server, it hosts a replica of the DomainDNSZones naming context for its domain and the ForestDNSZones naming context for the forest.

Okay, with all that out of the way, let's look at permissions.

The Enterprise Admins group and the Domain Admins group from the forest root domain are given Full Control access over the Configuration and Schema naming contexts. Domain Admins in other domains can view the contents of the forest-wide naming contexts, but they can't make changes to them. So, the administrator in the child domain might be able to launch ADSIEdit but that admin can't use it to changes to the objects in the Configuration or Schema naming context.

One exception to this rule are the replication objects that you can see in Active Directory Sites and Services. The Domain Admins group in a domain is given Full Control access to replication objects representing servers in that domain.

A dedicated root avoids the situation where a Domain Admin may would have vast privileges in a forest simply because he or she just happens to log onto the forest root domain. By limiting the accounts in the forest root domain, you control the number of super-admins in a forest.

This is not an absolute security barrier, though. It's fairly trivial to get local system access to the Configuration NC at a child domain controller, which essentially grants you the same full access rights as Enterprise Admins.

Here's a simple hack that permits an administrator with access rights to a domain controller in a child domain to "shift identity" and get access as the Local System account.

First, check the current time. At a command prompt, enter the following, and specify a time that is one minute later than the current time:

at 11:31 /interactive cmd

This uses the AT command to start an interactive console session.

When the console window opens, it runs as Local System. The Local System account on a domain controller has wide-ranging privileges in Active Directory, including full read-write access to the Configuration naming context.

You can and should audit for changes to Active Directory object permission. If you want to get a more secure barrier, then you'll need to install separate forests, but this limits interoperability, especially if you run Exchange.

Hope this helps.