Win Server 2008 Directory Services, Auditing Page 2

Keep in mind, however, their content is limited to more common attributes and does not include their original value. To address these shortcomings, you must enable Directory Service Changes subcategory of DS Access category, which can be accomplished by executing on a monitored domain controller AUDITPOL /SET /SUBCATEGORY:"Directory Service Changes" /success:enable. This command must be executed from an interactive session on the target server. As the result, you will be able to keep track of the following actions (as long as appropriate SACLs have been applied to target objects):

  • Creating a New Object: Resulting in multiple Event ID 5137 entries containing all attributes provided explicitly by the security principal that invoked the operation (but not those automatically generated by the system). Note that similar information also gets recorded if audit of User Account Management or Directory Service Access is enabled.
  • Modifying an Existing Object: Resulting in two Event ID 5136 entries including affected values, pre- and post-modification for all modified attributes. A single entry is created if the original value was not set. As mentioned earlier, such information is not available via ether User Account Management or Directory Service Access logging.
  • Moving an Existing Object: Resulting in a single Event ID 5139 entry containing its old and new location (in the distinguished name format), unless the target location is in a different domain, in which case, the operation is treated as creation of a new object (Event ID 5137).
  • Undeleting an Object: Resulting in a single Event ID 5138 entry containing its old and new locations (since it involves moving it from the cn=deleted Objects hidden container in its domain partition), in addition to any attributes explicitly assigned during this process.
  • Deleting an Object: Resulting in a single Event ID 5141 entry providing information about a user that invoked the deletion and identifying the object via its distinguished name. At the same time, a corresponding Directory Service Access event gets generated as well.

As mentioned earlier, in order for Directory Service Change and Directory Service Access events to be audited, you also must ensure that appropriate system access control list (SACL) entries are in place (in addition to enabling both types of audit subcategories). For domain objects, they are typically defined via a graphical interface of standard administrative utilities (DSACLS command line utility is capable only of restoring default SACL for an object based on its Schema definition), such as Active Directory Users and Computers (Auditing tab of Advanced Security Settings dialog box referencing a designated object).

Discuss this article in the ServerWatch discussion forum

Unsure About an Acronym or Term?
Search the ServerWatch Glossary

Each of such entries associates an action (or more specifically, its successful or failed outcome), one or more security principals initiating it (designated typically via a domain security group), and its target. Providing that all of these parameters match the respective circumstances of an actual event, its occurrence is recorded in the Security Event log. For example, enabling an audit of a successful creation of all types of descendant objects by Everyone on an arbitrarily chosen OU will yield an audit trail enabling you to keep track of Directory Service Changes events with ID 5137 affecting its content. Similarly, tracking usage of Write all properties for the same subject and object pair will allow you to monitor Directory Service Changes events with ID 5136 (in both cases, these actions will be recorded via corresponding Directory Service Access and User Account Management Security Event log entries).

As you might imagine, without proper planning, just a sheer volume of logged events might become overwhelming and render your auditing difficult to manage. Even though you can eliminate the risk of overwriting logs due to reaching their size limit by taking advantage of Archive the log when full, do not overwrite events configuration setting, which automatically dumps content of the log once it becomes full (this requires a registry modification in earlier versions of Windows). You should instead consider narrowing down a scope of monitoring to absolute minimum. One way to accomplish this goal is to target only specific object types, security principals or actions (via SACLs). Alternatively, you can turn off individual audit subcategories (e.g.,, rely on Directory Service Change rather than Directory Service Access).

If you decide to use that approach, keep in mind that category-level changes configured via Audit Policy node of a Group Policy Object linked to Default Domain Controllers organizational unit are applied in the uniform manner to all of underlying subcategories, which might not be what you want to accomplish. To prevent this from happening, enable Audit: Force audit policy subcategory setting (Windows Vista or later) to override audit policy category settings option (under Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options node of the applicable GPO within Group Policy Management Editor). In addition, once you begin to rely on subcategories to establish your audit policies, each domain controller will need to be individually configured (since AUDITPOL does not have remoting capabilities and its settings are not automatically replicated).

Another method that allows you to limit scope of generated events involves a schema modification. While, by default, auditing is enabled for all attributes, you have an option to exclude arbitrarily chosen ones from being a subject to the "Directory Service Change" policy. This requires setting the 9th bit of the SearchFlags property of a designated attribute to 1 (which corresponds to decimal value of 256 or 0x100 in hex notation — labeled as NEVER_AUDIT_VALUE in the ADSI Edit console).

Besides all features described above, you might also want to take advantage of improvements first made available in Vista as part of Windows Eventing 6.0 feature set. They include such functionality as event subscriptions (facilitating forwarding selected events to a designated host serving as an event collector) or integration with task scheduling (the ability to trigger an custom task based on occurrence of an event matching set of filter conditions, configurable from both Task Scheduler and Event Viewer interface), although you should consider their implementation with caution, due to potential performance and network load implications.

This concludes the discussion of auditing improvements in Windows Server 2008 Directory Services. The next article of our series will explore the role Distributed File System Replication plays in improving resiliency and performance of Active Directory domain infrastructure.

This article was originally published on Mar 12, 2009
Page 2 of 2

Thanks for your registration, follow us on our social networks to keep up-to-date