Win Server 2008 Directory Services, Auditing

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.

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.

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

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 (UserAccountManagement, ComputerAccountManagement, and SecurityGroupManagement) are, by default, also enabled.