WinSecWiki > Security Settings > Local Policies > Audit Policy

Audit Policy

An event in the Windows Security log is either type Success or type Failure. When you enable an audit policy you have the choice of enabling it for success events, failure events, or both, depending on the policy. All nine audit policies generate success events but only some of the policies generate failure events. Don’t fall for the recommendation to enable failure events only for each category. A common misconception is that a failure-only audit policy will alert you to all suspicious events. In reality, many of the most important events in the Security log are success events such as changes to critical user accounts and groups, account lockouts, and changes to security settings.

To view a system’s audit policy settings, you can open the Local Security Policy console on the computer and maneuver to Security Settings\Local Policies\Audit Policy, and, on Windows 2008 R2 and Windows 7, compare Security Settings\Advanced Audit Policy Configuration. It's very important to understand the difference between these 2 audit policy types and the role of "Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings". See below.)


When you open one of the audit policies, you may or may not be able to modify it, depending on whether the policy has been defined in a GPO that has been applied to the local system. If the computer is a member of an AD domain, the computer automatically applies appropriate GPOs from the domain. Any policy defined in a GPO overrides policies defined in the system’s local policy object and becomes the effective setting.

Windows Server 2003 and Windows XP always display the effective settings when in the Local Security Settings dialog box. (If you can modify the setting, the policy isn’t defined in any applicable GPOs defined in AD.) Windows 2000's Local Security Policy console puts the system’s local setting from effective setting in separate columns.

I recommend that you use the Local Security Policy console only for viewing a system’s audit policy—not for configuring it. As with all security settings, the best practice is to use Group Policy to centrally manage your audit policy.

Versions earlier than Windows 2003 disable all nine audit policies by default. Windows 2003 enables a few categories by default but the options selected make no sense from a security standpoint. Use Group Policy to push out the audit policy you want rather than relying on default settings.

Post Windows 2003

With these versions of Windows, audit policy undergoes a major change. Each of the 9 audit policies now has 2 or more subcategories which can be individually enabled or disabled for success and failure. Make sure you understand and enable "Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings" before configuring with subcategories.

Windows Server 2008 pre R2 and Vista

Here's the crazy part: you can't configure audit subcategories with group policy! You can set subcategories only by using a command-line program called Auditpol. Auditpol cannot be run on a remote computer. That means that in order to configure a common audit policy at the subcategory level across your network, you must get each computer to locally execute the auditpol command with your desired audit policy settings. Important note: before using auditpol to enable or disable subcategories make sure you must enable "Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings". For a complete discussion of auditpol and how it interacts with this setting please see chapter 2 of my book, The Windows Security Log Revealed.

Windows Server 2008 R2 and Windows 7

Good news! Audit subcategories are now part of Group Policy. Look for the Advanced Audit Policy Configuration at the bottom of Security Settings.

Child articles:

Back to top


Additional Resources