Windows Server 2008: It's pretty much a given that auditing functionality is found within the OS these days. In Windows Server 2008, this means tracking Active-Directory-related events. This article examines how it works and steps through an implementation.
Computing environments have changed drastically in recent years, not only because of magnified focus on security but also as the result of range of compliance-driven initiatives affecting practically the entire IT landscape. In response to these new requirements, Microsoft has revised some of its earlier designs, improving effectiveness of auditing functionality built into the operating system. With the introduction of Windows Server 2008, these enhancements also influenced methodology that can be employed to track Active Directory related events. In this article, we will review its characteristics and provide details regarding its implementation.
While earlier versions of Active Directory domains (based on either Windows 2000 Server or Windows Server 2003) were able to capture changes affecting its objects (by employing Audit Policy incorporated into a Group Policy Object linked to the Domain Controllers organizational unit), its configuration was rather cumbersome to manage. In particular, GPO-based administration, with its limited range of settings (enable/disable of success/failure audit for 9 main event categories) left you with a dubious choice of one of two extremes dealing with an overwhelming volume of events overwriting Security logs on a frequent basis or having no oversight at all. This could be somewhat mitigated by restricting the scope of monitoring to more sensitive accounts only, although such an approach hardly qualified as a solution to the problem. In addition, the description of some events was frequently considered to be inadequate. The most common complaint referred to the absence of before and after values in entries corresponding to successful changes of object attributes.
In Windows Server 2008-hosted domain controllers, some of these issues have been resolved. In particular, it became possible to narrow down the scope of auditing, at least to some extent, by taking advantage of event subcategories. Recorded information offers more visibility into the actual impact of a change, by including before and after values. Some caveats apply, such as string data type length limits or a provision that prevents inclusion of binary values, which are simply replaced with the
The new level of granularity still leaves room for improvement and management methodology lacks consistency; it is based on a combination of graphical and command line utilities. Note also that although the new features do not require elevated domain functional level, they are specific to Windows Server 2008, so you must upgrade all of your domain controllers if you want to be certain every change to Active Directory accounts gets audited in a consistent manner. Finally, keep in mind that for an audit event to be triggered, a target object must have its system access control list (SACL) properly configured, regardless of the version of the operating system.
With the new functionality in place, content of the Audit Policy subnode of the Default Domain Controller Group Policy Object on a Windows Server 2008 (under
Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies node within Group Policy Management Editor) might no longer give you an accurate representation of the actual configuration. To obtain it, you must resort to the
AUDITPOL command line utility, which provides the equivalent information, but on per-subcategory level. To better understand its structure, execute
AUDITPOL /GET /CATEGORY:*, which will display a full listing of categories along with all subcategories for each. Alternatively, if you are interested in a specific one, replace the
* parameter with its name (enclose multi-word terms in double quotes), according to the following list:
System - for the
Audit system events GPO setting
Logon/Logoff - for the
Audit logon events GPO setting
Object Access - for the
Audit object access GPO setting
Privilege Use - for the
Audit privilege use GPO setting
Detailed Tracking - for the
Audit process tracking GPO setting
Policy Change - for the
Audit policy change GPO setting
Account Management - for the
Audit account management GPO setting
Account Logon - for the
Audit account logon events GPO setting
DS Access - for the
Audit directory service access GPO setting
The last one of these entries, which is of particular interest to us, is divided into
Directory Service Changes,
Directory Service Access,
Directory Service Replication, and
Detailed Directory Service Replication subcategories, with the first two being most relevant from the security perspective. In its default configuration, Windows Server 2008 domain controllers track only successful events of
Directory Service Access type, which is consistent with the predefined Default Domain Controllers Policy settings in earlier versions of Active Directory. This arrangement allows you to capture an occurrence of each object change (via a corresponding access event), but without details about its impact or scope. Depending on the type of affected object, you might be able to track down more information by reviewing Security Log entries in the
User Account Management category, since successful events in three of its subcategories (
SecurityGroupManagement) are, by default, also enabled.
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).
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 Thursday Mar 12th 2009