In Through the Back Door
A routine audit of Active Directory permissions can expose this example back-ended breach.
- By Bill Boswell
- March 09, 2004
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:[email protected];
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.