In Through the Back Door

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

Bill: Can you clarify the purpose of using an empty or dedicated forest root in a Windows Server 2003 forest?

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.

Get Help from Bill

Got a Windows or Exchange question or need troubleshooting help? Or maybe you want a better explanation than provided in the manuals? Describe your dilemma in an e-mail to Bill at mailto:boswell@101com.com; the best questions get answered in this column.

When you send your questions, please include your full first and last name, location, certifications (if any) with your message. (If you prefer to remain anonymous, specify this in your message but submit the requested information for verification purposes.)

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.

About the Author

Contributing Editor Bill Boswell, MCSE, is the principal of Bill Boswell Consulting, Inc. He's the author of Inside Windows Server 2003 and Learning Exchange Server 2003 both from Addison Wesley. Bill is also Redmond magazine's "Windows Insider" columnist and a speaker at MCP Magazine's TechMentor Conferences.

comments powered by Disqus

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.