Now that you know what Active Directory is — and how vital it is — what are you doing to keep it safe?

Active Directory Data: Guarding the Family Jewels

Now that you know what Active Directory is — and how vital it is — what are you doing to keep it safe?

• By Roberta Bragg
• 01/01/2001

Windows 2000’s Active Directory has been called the central database, the data store, the key to all that’s sacred in Win2K, and the “crown jewel” of the Win2K family architecture. Without it, there can be no smoothly functioning organization, security infrastructure, network management, or centralized control. Data object definitions — including printers, computers, network shares, services, and user accounts — are stored here. Kerberos relies upon it — as do Group Policy and audit mechanisms. If you’re like most Windows aficionados, you’ve spent some time — some considerable time — during the last year or longer learning about it. Now that you know what Active Directory (AD) is — and how critical its operation is to the health and safety of your Win2K network — what are you doing to protect it?

Think about it. Like the registry in Windows NT, AD holds critical security information, including user accounts, computer accounts, password hashes, and permission/privilege settings on all servers and services.

So how is AD protected? Are there additional steps you need to take to defend it from attack? The answer is threefold: First, you should understand default security in Win2K and follow solid, generic security principles to protect your systems and your network. Second, you need to pay specific attention to the protection of the AD database and the objects within it. Finally, you need to pay attention to the change process itself — how AD data travels from domain controller to domain controller protected from modification and verified as to its source. While the answers aren’t all perfectly clear (after all, NT, Unix, and other OSs have been around for years, and we’re still finding out new things about protecting them), it’s time to survey your defenses.

Follow Solid Security Principles
Your first line of defense is to follow basic principles and practices, things like good physical security, strong file/folder and registry DACLs (discretionary access control list), keeping service packs and hot fixes current, managing the number of administrators, protecting passwords, tightening security options, securing backups, and so on. Yes, Win2K is a new operating system, but the principles of a strong defense remain the same.

Network security should also be a priority. Whenever possible, strong perimeter defenses and secure, remote-access processes such as firewalls, proxy servers, RADIUS, and virtual private networks (VPNs) should be appropriately configured and used. Alternative network access (access that goes around these perimeter defenses in either direction) should be forbidden.

Every methodology for choosing a higher level of security should be followed when possible, practical, and/or warranted by risk analysis. Consider using not just strong passwords, but perhaps smart cards or biometrics, not just access controls, but encrypted communications.

Protect the AD Database and Objects within AD
The best defense requires knowledge of what you’re defending. Let’s look.

The Best Defense Begins at Home
AD may have virtual existence — its changes are replicated to its structure throughout the forest — but it’s essentially a database that consists of a single database file, ntds.dit. This file is in the 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 database file.

Protection Partitions
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 management.

• 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 configuration.

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 DACLs.

• 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 Different Classes
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 OU DACLs.)

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.

Configuring 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 2.

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 Press).

You can, of course, modify permissions on these other properties programmatically.

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.)

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 objects.

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 container.

Extended Rights
Microsoft classifies access rights (permissions) into several categories:

• 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 (change 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 Auditing Changes
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 communications.

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 to:

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 configuration container.

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 replication connectors.

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.

The 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 service levels. 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) LDAP — Lightweight Directory Access Protocol ADSI — Active Directory Service Interface, which are COM interfaces to AD Win2K Administrative Tools Replication transports (RPC, SMTP ) Ntdsutil — A command-line tool for administering the database 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 Bragg

Thoughts on Additional Replication Process Security
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 in administration.

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 security by:

• Changing the domain controller security policy to require digital signature “always.”

• Requiring IPSec encryption between domain controllers for replication.

• 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.