Chapter 9
Directory Service Access Events

Whereas Account Management events provide excellent auditing of user, group, and computer maintenance, Directory Service Access events make low-level auditing available for all types of objects in AD. Directory Service Access events not only identify the object that was accessed and by whom but also document exactly which object properties were accessed.

The two core subcategories that provide this functionality are Directory Service Access and Directory Service Changes. The other two subcategories—Directory Service Replication and Detailed Directory Services Replication—have nothing to do with security. These two subcategories just provide diagnostic information about AD DC replication, and we recommend disabling them unless you get into a troubleshooting situation.

DS Access Subcategories	Comment
Directory Service Access	Similar to Object Access; use Auditpol to disable
Directory Service Changes	Most useful to track changes
Directory Service Replication	Mostly for operational troubleshooting; use Auditpol to disable
Detailed Directory Services Replication	Mostly for operational troubleshooting; use Auditpol to disable

What’s the difference between the Directory Service Access and Directory Service Changes subcategories? Directory Service Access allows you to track read-only operations on AD, whereas Directory Service Changes tracks modifications to AD objects and their properties. We recommend that you enable only the Directory Service Changes subcategory. AD is an LDAP directory and LDAP is all about looking up information. I’ve never encountered a situation in which we cared about tracking read access to AD. Modifications, however, are a different story.

Directory Service Access category events work a lot like Object Access events. First, you must enable the audit policy at the system level, then activate auditing on the specific objects you want to monitor. To enable auditing on an AD object, do the following:

1. Right-click an object in the MMC Active Directory Users and Computers snap-in and select Properties.
2. Select the Security tab in the Properties dialog box. (If you don’t see the Security tab, click View and then check Advance Features)
3. Click Advanced.
4. Select the Auditing tab in the Advanced Security Settings dialog box.
5. Specify the permissions that you want to audit when users request access to the object.

AD has two types of operations: operations that are performed against the object, and Read and Write operations that are performed against individual object properties. (Properties are individual settings within an object. For example, a user object has many properties, including phone number, photo, and account expiration date.) These two types of operations correspond to the Object tab and Properties tab.

Each class of object in AD has a set of applicable operations that you can perform on that object and on its properties. Certain permissions are common to all classes of objects:

• Full control
• List contents
• Read all properties
• Write all properties
• Delete
• Delete subtree
• Read permissions
• Modify permissions
• Modify owner

Some of these permissions are actually groups of lower-level permissions. For example, Full control gives Read and Write access to an object and to every property of that object. AD objects also have class-specific permissions that are appropriate for the object type. For example, user objects have a Reset password permission. And AD objects have Read and Write permissions for each object property. For example, user objects have individual Read/Write permissions for account expiration, company, department, and so forth. This setup allows for granular access control as well as granular auditing.

Just as defining audit policy at the folder level is preferable in file-system auditing, auditing at the OU level and allowing the audit policy to propagate down to the desired child objects is preferable in AD-object auditing. By default, permission and audit entries flow down through inheritance from parent OUs to child objects. This process lets you control permissions and auditing for entire branches of the domain at the highest appropriate level. You can customize an object’s audit policy to prevent the object’s parent’s audit entries from flowing down to it. If the object is an OU, you can also control whether and how audit entries flow from it to its children. When an object is created, its initial audit policy is derived by processing the parent’s audit policy. For container objects such as OUs, each audit entry's Apply onto setting specifies whether and how it should be propagated down to child objects. Here are use a few of the possible Apply onto settings:

• This object only
• This object and all child objects
• Child objects only
• Group objects
• Users objects
• Computer objects
• Organizational Unit objects

When the Apply these auditing entries to objects and/or containers within this container only check box in the Auditing Entry dialog box is selected, recursion is limited to the immediate OU; audit entries will not propagate below the immediate children of the OU. When an object is created, the system examines the parent’s audit policy and copies each applicable entry to the new object’s audit policy. Later, if the parent’s audit policy changes, the changes are repeated on the child. If the Include Inheritable Auditing from this object’s parents check box is subsequently cleared (in Advance Security Settings, Audit tab), then you can choose to have all inherited entries deleted from the object’s audit policy or added as non-inherited entries. All future changes to upper-parent audit policy will not propagate to the object unless you use the Clear All button to reset the audit policy to each object’s default.

Directory Service Access

We typically recommend disabling Directory Service Access and instead using the Directory Service Changes subcategory to track actual changes. The Directory Service Access category logs this event on DCs. You might recall that the Object Access category’s SAM subcategory (discussed in Chapter 7) logs event ID 4661 on member servers.

Event ID	Title
4661	A handle to an object was requested.
4662	An operation was performed on an object.

Event ID 4662 is the only way to track object access that the operating system does not consider a change. However, Read access to the AD is quite frequent and would generate many events.

Directory Service Changes

The Directory Service Changes subcategory, which generates events only on DCs, is useful for tracking changes to AD objects that have object-level auditing enabled. The events in the subcategory tell you not only which object and property were changed and by whom but also the new value of the affected properties. We highly recommend that you enable this subcategory for change control in AD.

Event ID	Title
5136	A directory service object was modified.
5137	A directory service object was created.
5138	A directory service object was undeleted.
5139	A directory service object was moved.
5141	A directory service object was deleted.

The example of event id 5136 on my website shows that a value has been added for the version number. If the number had been changed, you would find two events: one deleting the old value and another adding the new value. Both event instances will have the same Correlation ID if the action was performed in the same process at the same time.

Limiting Auditing for Some Attributes

A common complaint about Windows security logging is that it provides too much information. You can selectively disable auditing for certain object attributes.

1. Suppose, for example, that you don’t need to know about and don’t want to audit a user attribute such as home telephone number. In this case, you can set the attribute’s searchFlags property to 0x100 to prevent that attribute from being audited: Launch ADSI Edit and connect to the Schema Naming Context.
2. Navigate to the attribute (CN Phone-Home-Primary).
   
   
3. Open the CN’s Properties (right click).
4. Scroll to the searchFlags attribute, click edit and set to the hexadecimal value 0x100 = (NEVER_AUDIT_VALUE) in or the decimal value 256 = (NEVER_AUDIT_VALUE), then click OK.
   
   

You might encounter one problem when working with Directory Service Access events. Attribute names, as shown when you view an object’s properties in the MMC Active Directory Users and Computers snap-in, differ from the LDAP display names that are typically used in the event descriptions. To find an attribute’s LDAP display name, open the object’s Properties dialog box in the Active Directory Users and Computers snap-in, and then click the Attribute Editor tab. In this example the LDAP display name is homePhone.

When you view an object’s properties in the ADSI Edit schema, you’ll see the attribute’s container name (CN) and distinguished name (DN). In this example the CN is Phone-Home-Primary. Now, while viewing the ADSI Edit schema make sure that you have the correct attribute. To do so, right click the attribute and view the properties for that attribute, scroll down and check the lDAPDisplayName attribute on the ADSI Edit Attribute Editor tab.

To make changes to these attribute values, you must be a member of the Schema Admins group in the forest that holds the object. Because the need to make Schema changes is rare, best practice is to leave this group empty and have an Administrator add and then remove a member to the group as necessary.

Change Control Monitoring for AD

Windows Server provides a way to refine the auditing of AD Domain Services. Compliance issues have made the best practice of change control more important than ever, and nowhere is being able to determine who changed what more important than in AD. A misstep in AD can adversely affect thousands of users or computers, within minutes.

As mentioned in Chapter 8, the Account Management audit category amply supports change control for user, group, and computer maintenance. But administrators carry out plenty of other work in AD, and to track that you need to use Directory Service Access events. Two areas of AD maintenance that most frequently cause security or availability problems: changes to administrator authority and changes to Group Policy.

Tracking Changes to Administrator Authority in AD

Initially, all administrator authority in AD is controlled through the administrator and operator groups that are created when AD is installed. These groups include Enterprise Admins, Schema Admins, Domain Admins, Administrators, and Account Operators in particular. Larger IT departments that have specialized roles and separation of duty requirements should let only a handful of top-level administrators use these groups. Such organizations should take advantage of AD’s Delegation of Control feature, which you can use to follow least privilege and separation of duty—two precepts that are central to a mature, controlled IT security practice.

Top-level administrators can use AD’s delegation of control feature to delegate selected permissions over selected objects to groups that are created for various roles within IT. Suppose that the Help desk needs authority to reset passwords for forgetful users. Instead of making Help desk staffers members of the Administrators or Account Operators group, you can simply create a group called HelpDesk; then, in the ACL of each appropriate OU, grant the group Reset Password permission over user accounts.

Delegation of control in AD is essential to limit the risks posed by too many all-powerful administrators. But you obviously need a way to track delegation of control events. Directory Service Access events make this task easy. In general, AD authority is delegated at the root of the domain and in OUs. Therefore, you simply need to create two audit entries at the root of the domain.

We created one audit entry that activates auditing of Modify Permissions and Modify Owner on the root of the domain. Then we added another entry that audits the same permissions for OUs. Why not just use a single entry that applies to all objects from the domain root down? Such an audit policy would result in an overwhelming amount of events in the Security log when permissions are changed on an OU that has many child objects; you’d get an event for every object in that OU and below.

On my site, Event ID 5136, shows an instance in which ACME\Administrator has modified permissions on the AcmeManagers OU. The nTSecurityDescriptor attribute indicates that the discretionary ACL (DACL) was the focus of the change. Event ID 5136 gives details of the change (e.g., the permissions changed), alerts us to the fact that the ACL was changed, tells us which OU was affected, and who made the change. In Windows 2003 and earlier, such details were unknown, so event ID 5136 is a big improvement.

In addition to auditing permission changes on the domain root and OUs, you should audit changes to the ACLs of GPOs. There are two reasons for modifying GPO permissions. First, you might do so to give someone else the ability to edit the GPO. Second, you might use the Apply Group Policy permission to limit application of a GPO to a subset of users or computers that would otherwise receive the GPO’s policies. To enable the auditing of Modify Permission and Modify Owner for all current and future GPOs, do the following:

1. Open the Active Directory Users and Computers snap-in and enable View\Advanced Features, which reveals the System folder.
2. Maneuver to the System\Policies folder, which is the physical location of GPOs in AD.
3. Create the two audit entries, as defined, for the domain root and OUs, but select groupPolicyContainer objects as the choice for the Apply onto setting (groupPolicyContainer is the system name of GPOs in AD’s schema).

At this point, you’ll see an instance of event ID 5136 whenever someone modifies the permissions or takes ownership of the domain root, OUs, or GPOs. If you want even more change-control auditing, you can define similar audit policies on objects in the MMC Active Directory Sites and Services console, thus tracking changes to your forest’s site topology.

Tracking Changes to Group Policy

Group Policy is a powerful tool for managing thousands of computer configurations and user-level settings. As with any powerful tool, you can shoot yourself in the foot if you aren’t careful. A bad change in the wrong GPO can potentially take out an entire domain, so having an audit trail of Group Policy changes is an obvious requirement for any controlled environment.

To establish such an audit trail, add to the System\Policies folder an audit entry that activates auditing of the Write All Properties SACL on groupPolicyContainer objects. Then look for instances of event ID 5136 in which the object type is groupPolicyContainer, the Accesses field specifies Write Property, and the Properties field lists versionNumber. Whenever someone edits a GPO, AD increments the versionNumber property of the GPO. The specified audit policy will generate an event like the one depicted in Event ID 5136. To determine which GPO was changed, refer to the Object Name in the event’s description. Event ID 5136 doesn’t provide the GPO's friendly name, which you are accustomed to seeing in the Active Directory Users and Computers snap-in or the GPMC. Instead, the event lists the GPO's globally unique identifier (GUID). You can use the GPMC to figure out exactly which GPO that GUID identifies. (The GPMC was made available with Windows Server 2003 SP1 and replaces a variety of tools that were used in earlier versions.) Select a given GPO and go to the GPO’s Details tab. The Unique ID field specifies the GUID.

Besides directly modifying GPOs, you can also greatly alter the application of Group Policy by linking or unlinking a GPO to an OU, domain root, or site or by enabling the Block policy inheritance option on an OU. You manage GPO links and the policy inheritance in GPMC. You can install the GPMC on Windows XP or later machines and use it against any AD Domain in Windows 2000 and later. The GPMC greatly enhances understanding of AD because it allows you to see the details of links, OUs, Policies, Inheritance and more—all in one program.

By enabling auditing of OUs, domain roots, sites, and GPOs, you can effectively track changes in administrative authority and catch potentially wide-sweeping effects of Group Policy modifications.

Directory Service Replication

Directory Service Replication events simply tell you when replication begins and ends. These events are more operational than security-related and unless you’re doing troubleshooting, we recommend that you use Auditpol to disable this subcategory.

Event ID	Title
4932	Synchronization of a replica of an Active Directory naming context has begun.
4933	Synchronization of a replica of an Active Directory naming context has ended.

Detailed Directory Services Replication

Detailed Directory Services Replication events are even more elaborate than Directory Service Replication events. Although they might help locate replication problems, these events are also operational in nature, and we recommend using Auditpol to disable this subcategory as well.

Event ID	Title
4928	An Active Directory replica source naming context was established.
4929	An Active Directory replica source naming context was removed.
4930	An Active Directory replica source naming context was modified.
4931	An Active Directory replica destination naming context was modified.
4934	Attributes of an Active Directory object were replicated.
4935	Replication failure begins.
4936	Replication failure ends.
4937	A lingering object was removed from a replica.

Bottom Line

The Directory Service Changes subcategory makes it possible to know not only which objects have been changed by whom but also tells you the old and new values of the changed attributes. This additional information can make a responsible AD change-management function much more likely.