ntds folder. While
we want to protect its data as it travels, protecting
its physical location is the first priority — and it’s
one we can handle.
Quick, what’s the default security on the file? Is that
enough? Default security DACLs on ntds.dit are SYSTEM
and Administrators Full Control (yes, the local Administrators
group, not Domain Admins or Enterprise Admins, although—by
default—those groups are nested within the local Administrators
group.) These permissions are inherited from the ntds
folder. The ntds folder is set to not “Allow inheritable
permissions from parent to propagate to this object.”
Changing privileges on folders higher in the file hierarchy
can’t change privileges on the AD database file.
Are the default DACLs tight enough security? The SYSTEM
group, as an implicit group to which only the operating
system belongs, obviously needs this level of access.
(For information on how access to data within the database
is controlled, see “The Fortress: AD Data Manipulation.”)
Providing the Administrators group Full Control allows
for recovery and other “administrative” processing. If
we reduce either access, we could kill or cripple the
system or produce a result that’s meaningless. (Removing
Administrator Full Control is pointless since members
of the Administrators group can take ownership of any
file and then give themselves additional privileges.)
So is that the end of the story? Not by a long shot.
However, it’s important to know these defaults. If you
inspect this file and find a different scenario, then
you should suspect either ill-advised administration or
foul play. No other group or account needs or should have
privileges on this file. This doesn’t mean that Administrators
alone manage the AD, just that access to objects within
the AD, and management of these objects, is controlled
through DACLs set on the objects themselves, not on the
The Active Directory database consists of three basic
paritions or sections: Domain, Configuration, and Schema.
As you might expect, permissions on these partitions protect
them from modifications.
Full Control of the Configuration and Domain partitions
is granted to Domain Administrators and System. Read
permissions is granted to Authenticated Users.
Replication Directory Changes, Replication Synchronize
and Manage Replication Topology of the Domain, Configuration
and Schema permissions are granted to the Enterprise
Domain Controlers Groups and the built-in Administrators
Group. These permissions allow DCs to replicate and
automatically configure replication; and Administrators
to synchronize replication and participate in topology
Inheritable Full Control for the Configuraiton and
Domain partitions is enabled and given to the Enterprise
Administrators Group—this allows them control over
the configuration directory in the forest.
Inheritable Full Control for the Schema partition
is granted to the Schema Administrators group.
Inheritable Auditing to the Writes on all partitions
by the Everyone Group is enabled. This means that
enabling the audit policy will automatically record
writes to the directory on any object without further
Protecting Objects Within the Database
I’m not sure if anyone understands all of the implications
of all of the possible permission settings and their combinations
on all of the Active Directory objects. I know I don’t.
I do know that if I’m going to protect these objects,
I need to understand the DACLs; until I do, I’m going
to be very hesitant to follow some so-called expert’s
advice on changing them.
In NT, there was a limited set; it was easy to create
a chart that explained their meanings. It was clear that
the NT default settings were lax, yet it took some time
before we had solid information on the best settings.
Even so, we often had to relax them to allow applications
to run. Win2K provides a full range of default security
settings that seek to keep objects in the AD safe. Are
there areas where we should tighten those defenses? To
say there aren’t would court disaster. However, to guess
as to where and how that should be done would be an even
faster road to purgatory. What we can do is begin by seeking
a solid understanding of the objects and DACLs. The problems
in understanding Win2K Active Directory DACLs are as follows:
There are many classes of objects that may exist in
the AD; each class, or type, of object may have different
Many AD DACLs represent manipulation rights.
A new model of inheritance determines the extent
and hierarchical range of permission application.
Object permissions affect the object as a whole,
while additional Property permissions affect single
properties of the object.
Extended permissions aren’t fixed. New permissions
may be created.
Different DACLs for
The security properties of a computer object vs. a user
object vary. While this seems obvious, what’s not so obvious
is the sheer number of different DACLs we’re talking about.
No wonder there’s no comprehensive list to evaluate! Take
heart though; many of the DACLs in AD will be familiar.
Your job is to take each class of objects and determine
what the default settings mean and where you need to make
adjustments. This is no trivial task, and not one that
can be accomplished here. Your first efforts should be
to identify what you know — and what you don’t know.
DACLs and Rights
Part of the rationale behind all the muck that is AD DACLs
is that there’s a different philosophy concerning user
rights in Win2K than in NT. NT 4.0 provided inherent rights.
That is, the built-in administrative groups such as Administrators,
Server Operators, Power Users, and so on had built-in
or inherent rights. Those rights were given to users because
they were members of a group. User rights could also be
assigned, but inherent rights couldn’t be removed. Access
permissions (rights to access objects like files, registry
keys, and printers) were perceived as different entities
and applied via DACLs on the objects. Win2K, on the other
hand, has one inherent right — the right to control objects
you own. Other rights must be granted and can therefore
be taken away (with the exception that the Administrators
can take ownership of any object, thus they can control
the objects because they own them).
To see an example of this, consider the Server Operators
group. One right it has on Domain Controllers is the right
to “Shut down the system.” However, if you traverse Group
Policy to the User Rights node, you can remove the Server
Operators group from the right to “Shut down the system,”
and no server operator will have the right to shut down
the system! Not a useful change in most environments (don’t
do this at the office), but it does demonstrate the philosophy.
Figure 1 shows this right in Group Policy.
|Figure 1. In Windows 2000, non-owner,
non-Administrator access rights (such as "Shut down
the system") can be given, and taken away, via User
Rights. (Click image to view larger version.)
In Win2K, the difference between “rights” like “Shut
down the system” and access control (read, write, and
so forth) is blurred. The right to reset passwords is
something we normally think of as belonging to Administrators.
However, in Win2K, it can be applied via a DACL on an
Organizational Unit (OU). (We can do so by using the Delegation
of Authority wizard, but also by directly modifying the
This is easier to understand if we apply the concept
of “one inherent right” to AD objects. All objects are
owned. Since owners control the objects they own, permissions
to access objects — as well as the rights to manipulate
them — must find a way of being expressed and managed.
What better way than through the list of DACLs possible
on any object? This means, of course, that the possible
DACL list is expanded and may vary for each object. Using
DACLs to extend rights and make their application more
flexible also requires the capability to create new access
rights as objects are added to the directory.
To examine this new range of access rights, simply right-click
on an object in the AD and select Properties | Security
| Advanced. Selecting a group or user and clicking on
the Edit button exposes two tabs: Object and Properties.
Object and Property-Level Permissions
At the object level, the rights that are applied affect
the entire object. An example of the DACLs available at
the object level for a user object is visible in Figure
|Figure 2. The rights applied
at the object level affect the entire object.
Digging deeper, each user property—like department, division,
company, phone number, and so on—can also have permissions
assigned. To see these, select the Properties tab as shown
in Figure 3. Here you have the ability to assign rights
to specific properties such as “address,” “phone number,”
and so forth. Thus, perhaps domain users may read information
on a department, but phone numbers are only available
to human resource personnel or direct supervisors.
|Figure 3. By using the Properties
tab, you can assign permissions to specific properties.
Incidentally, the property page doesn’t list the entire
suite of properties for this object, only the most commonly
manipulated ones. To examine the complete list, you’ll
have to look at the schema. If you have permission and
the schema admin tool has been loaded, you can examine
the schema of your forest interactively. A printed copy
of properties available on objects in the default Win2K
schema can be found at http://msdn.microsoft.com
and found in the Active Directory Developer’s Reference
Library (a five-volume boxed set published by Microsoft
You can, of course, modify permissions on these other
Inheritance and Application
Two additional controls exist on access rights and permissions:
the selection of “Apply onto” for object types within
the container and the propagation of permissions via inheritance.
The drop-down box “Apply onto” in the initial Properties
page for an AD object further granularizes the ability
to apply permissions. A check box enables you to propagate
settings from parent objects.
Using the drop-down box, you can choose to apply configured
permissions to a wide range of child objects. (See “Setting
permissions via ‘Apply onto’” for a partial list.)
You can choose to apply configured
permissions to a wide range of child
objects, including the following:
- This object only
- This object and all child objects
- Child objects only
- ACSResource limits objects
- Certification Authority objects
- Computer objects
- Connection objects
- Contact object
- Group objects
- GroupPolicycontainer objects
- IntelliMirror group object
- IntelliMirror service object
- MSMQ configuration objects
- Organization Unit objects
- Printer objects
- Shared folder objects
- Site objects
- Site link object
- Site link bridge objects
- Site setting objects
- Sites container objects
- Subnet objects
- Subnets container objects
- Trusted domain objects
- User objects
The list of possibilities hints at their use. When changes
are made in the Permission window, I can choose to apply
those permissions to a limited set of objects within the
container. It’s like setting read permissions on the files
within a folder, but not for files nested within a subfolder.
The difference is that the file system only hosts files
and folders, while the AD hosts many different types of
Propagation of access rights to child containers is another
aspect that has changed from NT. You can protect security
configuration from inadvertent or malicious changes by
the inheritance of rights from parent containers by clearing
the “Allow inheritable permissions from parent to propagate
to this object.” This means that changes made at a higher
level in the AD hierarchy won’t affect settings on a nested
Microsoft classifies access rights (permissions) into
Generic — Rights like
Read, Write, and Execute.
Standard — Rights such
as Delete, Read_control (read permissions), Synchronize
(objects), Write_dac (modify DACLs), and Write_owner
SACL — Rights including
Read or change object System Access Control List (SACL)
or audit controls.
Object-specific — Each
object defines its own permissions.
Extended rights — Access
controls on custom actions or operations such as send_as.
Access controls on extended operations aren’t applied
by access mask but by globally unique identifiers (GUID).
The list of extended access rights isn’t fixed, but can
be programmatically extended by adding rights to the Extended
Access Rights container in the AD forest configuration
container. I’d audit this object for change.
Tightening Access Controls and
Before you can tighten access controls, you need to understand
them. You shouldn’t get hung up on the fact that understanding
all of them is a never-ending task. Instead, identify
critical and/or sensitive objects and concentrate your
efforts on these. For example, if you’re using secure
dynamic DNS, locking down write access to the DNS records
for domain controllers, DNS servers, and other critical
systems is one task that’ll help prevent redirection of
Once you understand the available permissions, privileges,
and problems that can impact AD and you’ve tightened controls
on sensitive objects where necessary, the final step to
protecting these jewels is to audit their use. Please
note that by audit I mean, set the system access control
lists (SACLs) so that access events and policy changes
are recorded in the security log and then monitor that
log. Which AD objects should you audit? To compile that
list, you’ll have to determine which objects are sensitive
in your environment; but I can give you a few to pay attention
Modifications to access rights for DNS records, including
servers and, especially, domain controllers, DNS servers,
DHCP servers, Certificate Servers, and Remote Access Servers.
Modification to access rights for these server objects.
Modification to access rights for certificate templates.
Changes to access rights to the ntds.dit file.
Changes to Group Policy Objects.
Extended Access Rights container in the AD forest
Protecting AD Data During Replication
The very nature of an “active” directory is that the data
is virtual. A Win2K client doesn’t have to authenticate
to a specific domain controller, nor does it have to know
location information for resources; it can search for
them in AD. Replication of data between domain controllers
in a domain and the replication of a subset of domain
directory information across the forest make this possible.
As administrators, we can protect the objects in AD by
setting and maintaining proper DACLs and SACLs on the
AD objects. How’s that data protected as it moves around
the world? How can you be sure that the data hasn’t changed
in transit? How do you know the data comes from trusted
sources and isn’t the result of a successful attack?
AD Replication Process Security
A good first step to understanding the replication process
in security is to understand the replication process.
Chapter 6 of the Windows 2000 Server Resource Kit Book,
“Distributed Services,” can help with the details. In
a nutshell, AD data is primarily multi-master — meaning
changes can be written to any domain controller (DC) within
a domain and then automatically replicated to other DCs.
A few replication operations follow the single-master
model. An example is the replication of schema changes.
Can an attacker force data changes to AD by pretending
to have changes that should be replicated? Four security/replication
concepts act in concert to thwart this and other types
of attacks via the replication process.
First, AD replication is pull replication. This means
that the destination domain controller (the DC to which
changes will be written) requests the changes from the
source (the DC advertising changes) providing change notification.
An attacking system can’t simply force changes to AD on
a destination domain controller by somehow sending them
the domain controller’s way. An attacking system would
have to masquerade as an authorized domain controller
and replication partner.
Second, connections between domain controllers for purpose
of replication are configured by the Knowledge Consistency
Checker (KCC) process. The KCC runs on every DC and modifies
data in AD in response to system-wide changes. It also
generates and maintains replication topology — the pathways
and connections used for communicating changes and replication.
A replication connection is a one-way, inbound route from
the source (the changed AD) DC to the destination DC.
Automatically created connections are “owned” by the KCC.
(Administrators can also create connections and modify
KCC-created connections. Administrators own connections
they create or modify. Administratively owned connections
are protected from automatic change by the KCC.) In fact,
permission on the Configuration, Schema and Domain partitions
of the AD control this. Replicating Directory Changes,
Replication Synchronize and Manage Replication Topology
permissions are given to the Enterprise Domain Controllers
group and to the built-in Administrator’s group. No user
interface exists for managing the KCC; however, replication
tasks can be managed via the AD Sites and Services console.
An attacker would need Administrative privileges to modify
Third, security between replication partners is provided
by mutual authentication: Each partner (DC) must prove
to the other that it is, indeed, the server it says it
is. Authentication between two Win2K DCs using RPC over
IP replication is provided by Kerberos. Authentication
between an NT BDC and a Win2K DC is provided by NTLM.
A certification-based authentication of systems can be
required if a Public Key Infrastructure (PKI) has been
created or enabled to perform the distribution and management
of machine certificates. In intrasite AD replication,
SMTP can be used for AD replication of configuration or
schema changes. In this case, certificates are required
(a PKI must be implemented) and are used for authentication.
Fourth, access control, or the setting of DACLs to determine
who can change AD data, will prevent unauthorized changes
to the AD at the source DC. The DS-Replication-Get-Changes
access right provides authorization for actual replication-based
changes. This right is granted, by default, to Enterprise
Domain Admins and to Domain Controllers. Administrators
need this right in order to run dcpromo (the AD installation
process). An attacker would need this right in order to
make replication-based changes programmatically or to
install a new domain controller in the domain he or she
wishes to use for the basis of attack.
Fortress: AD Data Manipulation
Inquiries and requests for additions
and changes must negotiate three service
levels before they’re able to successfully
reach the Active Directory database.
Figure A diagrams this process.
|Figure A. The
process of making modifications
to the AD database involves multiple
Various interfaces are provided and
include the following:
- Outlook clients
(using LDAP or MAPI) — MAPI to DSA
is via the MAPI remote procedure call
(RPC) Address Book provider interface
- Windows NT net
APIs (which use the SAM interface
to access and replicate directory
information with the AD)
— Lightweight Directory Access Protocol
— Active Directory Service Interface,
which are COM interfaces to AD
- Win2K Administrative
transports (RPC, SMTP )
— A command-line tool for administering
Excluding some Outlook MAPI calls,
most interfaces’ first contact is with
the Directory Systems Agent (DSA), which
provides APIs for directory access calls
and reads the SIDs in the access token
of the calling process. Next, DSA (and
those Outlook MAPI calls) interface
with the Database Layer, an abstraction
layer that sits between the database
and applications. No application calls
go directly to the Active Directory
database — they pass through the Database
Layer. Finally, the Database Layer communicates
with the Extensible storage engine that
directly accesses the records in the
directory data store.
The actual database file is protected
both by DACLs and via an organized approach
and process that incorporates several
layers and allows for security checks
on authorization. But what about attacks
that might seek to subvert this process
by providing their own version of the
code involved? A quick check on the
DACLs for system files will reveal that
their default security gives nothing
more than Read permissions to Administrators,
Server Operators, and the system.
So, could a malicious administrator
— or someone who has obtained administrative
access to the system and, thus, access
to these files — replace them? A second
protective layer is in place to protect
against this type of attack. This layer
is the Windows File Protection (WFP)
service. A Microsoft private key signs
all system files. A copy of the matching
public key is part of the Win2K system.
Each file’s veracity can be authenticated;
no system file can be replaced unless
it’s done with an official Microsoft
hot fix, service pack, or update process.
To substitute the "real" file with a
replacement file that subverts security
would require more than simple duplication
of .DLL processes and modification to
security code—it would first necessitate
an attack against the WFP.
Even so, you should guard access to
these files and audit for deletion or
other attempts at modification. —Roberta
Thoughts on Additional Replication
You can configure additional security. But what’s appropriate
for your enterprise? Each choice may come with additional
costs in the form of processing overhead, increased bandwidth
requirements, and the possibility of self-inflicted Denial
of Service when sophisticated security negotiations fail
due to improper configuration or other considerations.
Implementing the use of machine certificates for authentication
can provide additional authentication security. A PKI
must be implemented; thus creating additional overhead
To prevent the substitution of servers by manipulation
of IP addressing, you should secure automatic updates
to DNS records for domain controllers by setting DACLs
on these DNS records. You can provide additional transport
Changing the domain controller security policy to
require digital signature “always.”
Requiring IPSec encryption between domain controllers
Establishing and using Virtual Private Network connections
for replication purposes.
At this point, you should have a little better understanding
of what’s involved in protecting the corporate jewels.
Your knowledge of the default security settings, processes,
and issues should help you maintain a solid defense. However,
improving security will require that you continually update
your knowledge. Make sure you know how the system works.
Learn DACLs and their meanings. And, finally, pay attention
to new recommendations in the forms of hot fixes, settings,
and service packs.