Skip to content
Audit Policy Recommendations

Audit Policy Recommendations

learn.microsoft.com • October 7, 2026

Access to this page requires authorization. You can try signing in or changing directories .

Access to this page requires authorization. You can try changing directories .

Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012

This section addresses the Windows default audit policy settings, baseline recommended audit policy settings, and the more aggressive recommendations from Microsoft, for workstation and server products.

The SCM baseline recommendations shown here, along with the settings we recommend to help detect compromise, are intended only to be a starting baseline guide to administrators. Each organization must make its own decisions regarding the threats they face, their acceptable risk tolerances, and what audit policy categories or subcategories they should enable. For further information threats, refer to the Threats and Countermeasures Guide . Administrators without a thoughtful audit policy in place are encouraged to start with the settings recommended here, and then to modify and test, prior to implementing in their production environment.

The recommendations are for enterprise-class computers, which Microsoft defines as computers that have average security requirements and require a high level of operational functionality. Entities needing higher security requirements should consider more aggressive audit policies.

Microsoft Windows defaults and baseline recommendations were taken from the Microsoft Security Compliance Manager tool .

The following baseline audit policy settings are recommended for normal security computers that are not known to be under active, successful attack by determined adversaries or malware.

This section contains tables that list the audit setting recommendations that apply to the following operating systems:

Windows Server 2012 R2

Windows Server 2012 R2

These tables contain the Windows default setting, the baseline recommendations, and the stronger recommendations for these operating systems.

Audit Policy Tables Legend

Enable in general scenarios

Do not enable in general scenarios

Enable if needed for a specific scenario, or if a role or feature for which auditing is desired is installed on the machine

Enable on domain controllers

Windows 8 and Windows 7 Audit Settings Recommendations

Audit Policy Category or Subcategory

Audit Credential Validation

Audit Kerberos Authentication Service

Audit Kerberos Service Ticket Operations

Audit Other Account Logon Events

Audit Application Group Management

Audit Computer Account Management

Audit Distribution Group Management

Audit Other Account Management Events

Audit Security Group Management

Audit User Account Management

Audit Process Creation

Audit Process Termination

Audit Detailed Directory Service Replication

Audit Directory Service Access

Audit Directory Service Changes

Audit Directory Service Replication

Audit Account Lockout

Audit User/Device Claims

Audit IPsec Extended Mode

Audit IPsec Main Mode

Audit IPsec Quick Mode

Audit Network Policy Server

Audit Other Logon/Logoff Events

Audit Application Generated

Audit Certification Services

Audit Detailed File

Audit Filtering Platform Connection

Audit Filtering Platform Packet Drop

Audit Handle Manipulation

Audit Other Object Access Events

Audit Removable Storage

Audit Central Access Policy Staging

Audit Audit Policy Change

Audit Authentication Policy Change

Audit Authorization Policy Change

Audit Filtering Platform Policy Change

Audit MPSSVC Rule-Level Policy Change

Audit Other Policy Change Events

Audit Non Sensitive Privilege Use

Audit Other Privilege Use Events

Audit Sensitive Privilege Use

Audit Other System Events

Audit Security State Change

Audit Security System Extension

Audit System Integrity

Global Object Access Auditing

Audit Other System Events

Audit Security State Change

Audit Security System Extension

Audit System Integrity

Windows Server 2012, Windows Server 2008 R2, and Windows Server 2008 Audit Settings Recommendations

Audit Policy Category or Subcategory

Audit Credential Validation

Audit Kerberos Authentication Service

Audit Kerberos Service Ticket Operations

Audit Other Account Logon Events

Audit Application Group Management

Audit Computer Account Management

Audit Distribution Group Management

Audit Other Account Management Events

Audit Security Group Management

Audit User Account Management

Audit Process Creation

Audit Process Termination

Audit Detailed Directory Service Replication

Audit Directory Service Access

Audit Directory Service Changes

Audit Directory Service Replication

Audit Account Lockout

Audit User/Device Claims

Audit IPsec Extended Mode

Audit IPsec Main Mode

Audit IPsec Quick Mode

Audit Network Policy Server

Audit Other Logon/Logoff Events

Audit Application Generated

Audit Certification Services

Audit Detailed File

Audit Filtering Platform Connection

Audit Filtering Platform Packet Drop

Audit Handle Manipulation

Audit Other Object Access Events

Audit Removable Storage

Audit Central Access Policy Staging

Audit Audit Policy Change

Audit Authentication Policy Change

Audit Authorization Policy Change

Audit Filtering Platform Policy Change

Audit MPSSVC Rule-Level Policy Change

Audit Other Policy Change Events

Audit Non-Sensitive Privilege Use

Audit Other Privilege Use Events

Audit Sensitive Privilege Use

Audit Other System Events

Audit Security State Change

Audit Security System Extension

Audit System Integrity

Global Object Access Auditing

Audit Other System Events

Audit Security State Change

Audit Security System Extension

Audit System Integrity

Set Audit Policy on Workstations and Servers

All event log management plans should monitor workstations and servers. A common mistake is to only monitor servers or domain controllers. Because malicious hacking often initially occurs on workstations, not monitoring workstations is ignoring the best and earliest source of information.

Administrators should thoughtfully review and test any audit policy prior to implementation in their production environment.

A perfect event ID to generate a security alert should contain the following attributes:

High likelihood that occurrence indicates unauthorized activity

High likelihood that occurrence indicates unauthorized activity

Low number of false positives

Low number of false positives

Occurrence should result in an investigative/forensics response

Occurrence should result in an investigative/forensics response

Two types of events should be monitored and alerted:

Those events in which even a single occurrence indicates unauthorized activity

Those events in which even a single occurrence indicates unauthorized activity

An accumulation of events above an expected and accepted baseline

An accumulation of events above an expected and accepted baseline

An example of the first event is:

If Domain Admins (DAs) are forbidden from logging on to computers that are not domain controllers, a single occurrence of a DA member logging on to an end-user workstation should generate an alert and be investigated. This type of alert is easy to generate by using the Audit Special Logon event 4964 (Special groups have been assigned to a new logon). Other examples of single instance alerts include:

If Server A should never connect to Server B, alert when they connect to each other.

If Server A should never connect to Server B, alert when they connect to each other.

Alert if a normal end-user account is unexpectedly added to a sensitive security group.

Alert if a normal end-user account is unexpectedly added to a sensitive security group.

If employees in factory location A never work at night, alert when a user logs on at midnight.

If employees in factory location A never work at night, alert when a user logs on at midnight.

Alert if an unauthorized service is installed on a domain controller.

Alert if an unauthorized service is installed on a domain controller.

Investigate if a regular end-user attempts to directly log on to a SQL Server for which they have no clear reason for doing so.

Investigate if a regular end-user attempts to directly log on to a SQL Server for which they have no clear reason for doing so.

If you have no members in your DA group, and someone adds themselves there, check it immediately.

If you have no members in your DA group, and someone adds themselves there, check it immediately.

An example of the second event is:

An aberrant number of failed logons could indicate a password guessing attack. For an enterprise to provide an alert for an unusually high number of failed logons, they must first understand the normal levels of failed logons within their environment prior to a malicious security event.

For a comprehensive list of events that you should include when you monitor for signs of compromise, please see Appendix L: Events to Monitor .

Active Directory Objects and Attributes to Monitor

The following are the accounts, groups, and attributes that you should monitor to help you detect attempts to compromise your Active Directory Domain Services installation.

Systems for disabling or removal of antivirus and antimalware software (automatically restart protection when it is manually disabled)

Systems for disabling or removal of antivirus and antimalware software (automatically restart protection when it is manually disabled)

Administrator accounts for unauthorized changes

Administrator accounts for unauthorized changes

Activities that are performed by using privileged accounts (automatically remove account when suspicious activities are completed or allotted time has expired)

Activities that are performed by using privileged accounts (automatically remove account when suspicious activities are completed or allotted time has expired)

Privileged and VIP accounts in AD DS. Monitor for changes, particularly changes to attributes on the Account tab (for example, cn, name, sAMAccountName, userPrincipalName, or userAccountControl). In addition to monitoring the accounts, restrict who can modify the accounts to as small a set of administrative users as possible.

Privileged and VIP accounts in AD DS. Monitor for changes, particularly changes to attributes on the Account tab (for example, cn, name, sAMAccountName, userPrincipalName, or userAccountControl). In addition to monitoring the accounts, restrict who can modify the accounts to as small a set of administrative users as possible.

Refer to Appendix L: Events to Monitor for a list of recommended events to monitor, their criticality ratings, and an event message summary.

Group servers by the classification of their workloads, which allows you to quickly identify the servers that should be the most closely monitored and most stringently configured

Group servers by the classification of their workloads, which allows you to quickly identify the servers that should be the most closely monitored and most stringently configured

Changes to the properties and membership of following AD DS groups: Enterprise Admins (EA), Domain Admins (DA), Administrators (BA), and Schema Admins (SA)

Changes to the properties and membership of following AD DS groups: Enterprise Admins (EA), Domain Admins (DA), Administrators (BA), and Schema Admins (SA)

Disabled privileged accounts (such as built-in Administrator accounts in Active Directory and on member systems) for enabling the accounts

Disabled privileged accounts (such as built-in Administrator accounts in Active Directory and on member systems) for enabling the accounts

Management accounts to log all writes to the account

Management accounts to log all writes to the account

Built-in Security Configuration Wizard to configure service, registry, audit, and firewall settings to reduce the server’s attack surface. Use this wizard if you implement jump servers as part of your administrative host strategy.

Built-in Security Configuration Wizard to configure service, registry, audit, and firewall settings to reduce the server’s attack surface. Use this wizard if you implement jump servers as part of your administrative host strategy.

Additional Information for Monitoring Active Directory Domain Services

Review the following links for additional information monitoring AD DS:

Global Object Access Auditing is Magic – Provides information configuring and using Advanced Audit Policy Configuration that was added to Windows 7 and Windows Server 2008 R2.

Global Object Access Auditing is Magic – Provides information configuring and using Advanced Audit Policy Configuration that was added to Windows 7 and Windows Server 2008 R2.

Introducing Auditing Changes in Windows 2008 – Introduces the auditing changes made in Windows 2008.

Introducing Auditing Changes in Windows 2008 – Introduces the auditing changes made in Windows 2008.

Cool Auditing Tricks in Vista and 2008 – Explains interesting new features of auditing in Windows Vista and Windows Server 2008 that can be used for troubleshooting problems or seeing what’s happening in your environment.

Cool Auditing Tricks in Vista and 2008 – Explains interesting new features of auditing in Windows Vista and Windows Server 2008 that can be used for troubleshooting problems or seeing what’s happening in your environment.

One-Stop Shop for Auditing in Windows Server 2008 and Windows Vista – Contains a compilation of auditing features and information contained in Windows Server 2008 and Windows Vista.

One-Stop Shop for Auditing in Windows Server 2008 and Windows Vista – Contains a compilation of auditing features and information contained in Windows Server 2008 and Windows Vista.

AD DS Auditing Step-by-Step Guide – Describes the new Active Directory Domain Services (AD DS) auditing feature in Windows Server 2008. It also provides procedures to implement this new feature.

AD DS Auditing Step-by-Step Guide – Describes the new Active Directory Domain Services (AD DS) auditing feature in Windows Server 2008. It also provides procedures to implement this new feature.

General List of Security Event ID Recommendation Criticalities

All Event ID recommendations are accompanied by a criticality rating as follows:

High: Event IDs with a high criticality rating should always and immediately be alerted and investigated.

Medium: An Event ID with a medium criticality rating could indicate malicious activity, but it must be accompanied by some other abnormality (for example, an unusual number occurring in a particular time period, unexpected occurrences, or occurrences on a computer that normally would not be expected to log the event.). A medium-criticality event may also r be collected as a metric and compared over time.

Low: And Event ID with a low criticality events should not garner attention or cause alerts, unless correlated with medium or high criticality events.

These recommendations are meant to provide a baseline guide for the administrator. All recommendations should be thoroughly reviewed prior to implementation in a production environment.

Refer to Appendix L: Events to Monitor for a list of the recommended events to monitor, their criticality ratings, and an event message summary.

Last updated on 2016-08-31