Windows Insider

Auditing Doesn't Have to Stink

Both Vista and Windows Server 2008 make logging and retrieving event data easier.

• By Greg Shields
• 09/01/2008

Complaining about such matters may be coming to an end. With the release of Windows Vista and Windows Server 2008, Microsoft has taken a hard look at the Windows auditing and Event Log subsystems. Vista and Server 2008 now come equipped with a host of new features that make these tools for logging and retrieving critical event data useable.

New Features
The new features in the Event Log are fairly obvious the moment you look at its new interface, discover its sorting and filtering capabilities, and look at its log-shipping abilities. In previous versions of Windows, it was difficult to narrow down the types of security events logged to the Security Event Log. Windows XP and Windows Server 2003 enabled only nine possible event categories that determined what kinds of events actually made their way into the log. These event categories all allowed overly broad categories of events to be stored.

Turning on auditing for a wide swath of events like Audit Account Management would effectively enable logging for every addition, deletion or change of an Active Directory object like users or groups. This resulted in a Security Event Log with tens or thousands of events, making parsing and retrieval difficult.

A lot of IT environments don't need that level of data. If an IT environment requires awareness of changes to user accounts, but couldn't care less about changes to groups or computer accounts, it's stuck with both sets of data using yesterday's audit policy. Vista and Server 2008 fix this problem by adding more granular "subcategories." By breaking the original categories down into 50 subcategories, it's possible now to better pare down the quantity and type of data you're storing in your Security Event Log.

Granularity's Dark Side
Along with the good side of this change, there's also a bad side: These new, more granular subcategories can only be enabled from the command prompt. While the original nine categories could be globally configured using Group Policy, today's implementation of their subcategories is set up locally using the command-line tool auditpol.exe. This means you'll need to configure them individually on each machine of interest.

Let's look at an example of this. One new audit category of interest for many IT organizations is the ability to log changes to the configuration of AD. Let's assume you want to create a log entry every time a change is made to the configuration of an AD object or one of its attributes. This is information that can be important for successfully passing a compliance audit. Knowing what the previous as well as the new value of the changed object was and is can also be handy in troubleshooting what got changed.

Vista and Server 2008 include a new log subcategory for the Audit Directory Service Access category called Audit Directory Service Changes that can provide just this kind of data. Enabling this new subcategory lets you begin tracking these changes and their "before" and "after" values through four new event-log entries that show the modification (Event ID 5136), creation (Event ID 5137), undeletion (Event ID 5138) and movement (Event ID 5139) of AD objects or their attributes.

Three other subcategories are available for Audit Directory Service Access. They are Directory Service Access, Directory Service Replication and Detailed Directory Service Replication.

When it comes to auditing and event retrieval, chalk up another win for Vista and Server 2008. Although these new, more granular auditing categories can be more complicated to enable, their ability to tailor your log data to just what you want helps reduce the noise.