Active Directory Audit Policy: DC Settings and 35 Key Event IDs

An Active Directory audit policy decides which security events your domain controllers write to the Security log: sign-ins, failed passwords, lockouts, new accounts, group membership changes and edits to directory objects. Without one, you cannot answer “who added this user to Domain Admins?” or “where is this lockout coming from?”. This guide shows how to build it with Advanced Audit Policy Configuration on Windows Server 2016 to 2025, which subcategories to enable on DCs, the event IDs to watch, and how to query and forward them.

Short answer: Edit a GPO linked to the Domain Controllers OU, go to Computer Configuration » Policies » Windows Settings » Security Settings » Advanced Audit Policy Configuration » Audit Policies, and enable Success and Failure for Credential Validation, Kerberos Authentication Service, Kerberos Service Ticket Operations, User Account Management and Logon, plus Success for Security Group Management, Computer Account Management and Directory Service Changes. Make sure “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings” is Enabled, raise the Security log size, and verify with auditpol /get /category:*.

Which method to use

Method	Granularity	Scope	Pros	Cons
Advanced Audit Policy Configuration (GPO)	About 60 subcategories	All DCs via the Domain Controllers OU	Precise, low noise, central	Must not be mixed with the legacy settings
Legacy audit policy (Local Policies » Audit Policy)	9 categories	GPO or local	Simple	Enables whole categories, very noisy; overridden by subcategories
auditpol.exe	Subcategories	One machine	Quick testing and reporting	Overwritten by GPO at the next refresh
Microsoft security baselines (Security Compliance Toolkit)	Subcategories	Imported into a GPO	Microsoft-tested values	Contains many non-audit settings; review before importing

Use Advanced Audit Policy Configuration in a GPO. Legacy categories and subcategories should never be configured together: when both apply, the result is hard to predict and hard to troubleshoot.

Prerequisites

Before you change the Active Directory audit policy on production DCs, check the following:

• Domain controllers running Windows Server 2016, 2019, 2022 or 2025. The subcategories below exist on all of them.
• Rights to create and link GPOs on the Domain Controllers OU.
• A plan for log storage: DC Security logs fill quickly, so decide on log size and on forwarding to a collector or SIEM before you enable more auditing.
• For Directory Service Changes, rights to edit the SACL (auditing entries) on the domain partition or OUs.

Step 1: enforce subcategory settings

The setting Computer Configuration » Policies » Windows Settings » Security Settings » Local Policies » Security Options » "Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings" tells Windows to ignore the legacy category settings when subcategories are configured. It is enabled by default on DCs and member servers; set it to Enabled explicitly in your DC audit GPO so nobody turns it off by accident.

Then check the GPOs linked to the Domain Controllers OU and the domain, including the Default Domain Controllers Policy, and set anything under Local Policies » Audit Policy to Not Defined. The Active Directory audit policy should live in exactly one place.

Step 2: configure the audit subcategories

1. In Group Policy Management, create a GPO named, for example, DC – Audit Policy and link it to the Domain Controllers OU.
2. Edit it and go to Computer Configuration » Policies » Windows Settings » Security Settings » Advanced Audit Policy Configuration » Audit Policies.
3. For each subcategory in the table below, open it, tick Configure the following audit events and tick Success, Failure or both.
4. Run gpupdate /force on a DC and check with auditpol /get /category:*.

Recommended subcategories for domain controllers

This is our recommended Active Directory audit policy baseline, in line with Microsoft’s security baseline for domain controllers. Subcategories not listed can stay at their defaults.

Category	Subcategory	Setting	Why
Account Logon	Audit Credential Validation	Success, Failure	NTLM authentications (4776)
Account Logon	Audit Kerberos Authentication Service	Success, Failure	TGT requests and pre-authentication failures (4768, 4771)
Account Logon	Audit Kerberos Service Ticket Operations	Success, Failure	Service tickets (4769); high volume, useful for Kerberoasting detection
Account Management	Audit Computer Account Management	Success	Computers created, changed, deleted
Account Management	Audit Other Account Management Events	Success	Password policy reads and similar
Account Management	Audit Security Group Management	Success	Group membership changes
Account Management	Audit User Account Management	Success, Failure	Created, enabled, disabled, deleted, locked out, unlocked
DS Access	Audit Directory Service Access	Success, Failure	Access to objects with a SACL (4662); can be noisy
DS Access	Audit Directory Service Changes	Success	Old and new attribute values (5136); needs SACLs
Logon/Logoff	Audit Account Lockout	Failure	Logon attempts against a locked account
Logon/Logoff	Audit Logon	Success, Failure	Logons to the DC itself (4624, 4625, 4648)
Logon/Logoff	Audit Logoff	Success	4634, 4647
Logon/Logoff	Audit Special Logon	Success	Privileged logons (4672)
Logon/Logoff	Audit Other Logon/Logoff Events	Success, Failure	RDP reconnects, screen lock and unlock
Policy Change	Audit Audit Policy Change	Success	Someone changed the audit policy (4719)
Policy Change	Audit Authentication Policy Change	Success	Trusts, Kerberos policy and user rights changes
Privilege Use	Audit Sensitive Privilege Use	Success, Failure	Use of powerful rights such as taking ownership
System	Audit Security State Change, Security System Extension, System Integrity	Success (Integrity: Success, Failure)	Startup, shutdown, service installs and integrity problems
Detailed Tracking	Audit Process Creation	Success	Process launches (4688) on the DC

The Account Logon subcategories matter most on DCs, because domain user sign-ins to workstations are authenticated there. The resulting 4624 logon event is written on the workstation, not the DC. To see workstation logons centrally, you need the Active Directory audit policy on DCs for Kerberos and NTLM events plus a separate audit GPO for member computers.

Enable Directory Service Changes auditing

Directory Service Changes events (5136 to 5141) are only generated for objects whose SACL has a matching auditing entry. To audit changes to users and groups across the domain:

1. In Active Directory Users and Computers, enable View » Advanced Features.
2. Open the properties of the domain root (or a specific OU), go to Security » Advanced » Auditing and click Add.
3. Select principal Everyone, Type Success, Applies to This object and all descendant objects, and tick Write all properties, Delete and Delete subtree. Also tick Create all child objects if you want 5137 events for new objects.
4. Apply. Changes now produce 5136 with the attribute name, old value and new value.

Start narrow if your domain is large: audit high-value objects such as the AdminSDHolder container, privileged groups and the OUs holding servers and admin accounts.

Key event IDs to monitor

Once the Active Directory audit policy is in place, these are the events worth reading, alerting on or forwarding:

Event ID	Meaning	Subcategory
4624	An account was successfully logged on (check the logon type)	Logon
4625	An account failed to log on	Logon
4634 / 4647	An account was logged off / user-initiated logoff	Logoff
4648	A logon was attempted using explicit credentials (runas, mapped drive with other credentials)	Logon
4672	Special privileges assigned to new logon (admin sign-in)	Special Logon
4720	A user account was created	User Account Management
4722 / 4725	A user account was enabled / disabled	User Account Management
4723 / 4724	Attempt to change / reset an account’s password	User Account Management
4726	A user account was deleted	User Account Management
4738	A user account was changed	User Account Management
4740	A user account was locked out (logged on the PDC emulator and the DC that processed it)	User Account Management
4767	A user account was unlocked	User Account Management
4794	Attempt to set the DSRM administrator password	User Account Management
4728 / 4729	Member added to / removed from a security-enabled global group	Security Group Management
4732 / 4733	Member added to / removed from a security-enabled local (domain local) group	Security Group Management
4756 / 4757	Member added to / removed from a security-enabled universal group	Security Group Management
4741 / 4743	Computer account created / deleted	Computer Account Management
4768	A Kerberos TGT was requested (failure codes show bad user names, expired or disabled accounts)	Kerberos Authentication Service
4769	A Kerberos service ticket was requested	Kerberos Service Ticket Operations
4771	Kerberos pre-authentication failed (wrong password; shows the client IP)	Kerberos Authentication Service
4776	The DC attempted to validate the credentials for an account (NTLM)	Credential Validation
4662	An operation was performed on an object	Directory Service Access
5136 / 5137 / 5139 / 5141	Directory object modified / created / moved / deleted	Directory Service Changes
4719	System audit policy was changed	Audit Policy Change
1102	The Security log was cleared	Logged whenever the log is cleared

Treat 4728, 4732 and 4756 for Domain Admins, Enterprise Admins, Schema Admins and Administrators, plus 4719 and 1102, as alerts rather than log entries: they should never happen without a change ticket.

Manage the policy with auditpol

auditpol.exe shows the effective policy on a DC and is useful for testing. Values set with it are replaced by the GPO at the next refresh.

auditpol /get /category:*
auditpol /get /subcategory:"User Account Management","Security Group Management"
auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable
auditpol /list /subcategory:* /v
auditpol /backup /file:C:\Temp\dc-audit.csv
auditpol /restore /file:C:\Temp\dc-audit.csv

Subcategory names are localised; on non-English servers use the GUIDs from auditpol /list /subcategory:* /v instead. The GPO stores its Active Directory audit policy in audit.csv under Machine\Microsoft\Windows NT\Audit in the GPO’s SYSVOL folder.

Size the Security log

With the settings above, a busy DC can write thousands of events per minute. If the log is too small, older events are overwritten before anyone looks at them. Configure the size in the same GPO:

• Computer Configuration » Policies » Administrative Templates » Windows Components » Event Log Service » Security » "Specify the maximum log file size (KB)". Size it so the log holds at least one to two weeks of events; on busy DCs that often means 1 to 4 GB.
• "Control Event Log behavior when the log file reaches its maximum size": leave it Disabled (overwrite old events) unless you archive, because stopping logging on a DC is worse.
• "Back up log automatically when full": only with a disk and retention plan for the archived files.

Check the current size and change it on one DC for testing:

wevtutil gl Security
wevtutil sl Security /ms:2147483648

Query events with PowerShell

Use Get-WinEvent with -FilterHashtable so filtering happens in the event log service, not in PowerShell:

Get-WinEvent -ComputerName DC01 -FilterHashtable @{LogName='Security'; Id=4740; StartTime=(Get-Date).AddDays(-1)} |
  ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}; $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{ Time = $_.TimeCreated; User = $d.TargetUserName; CallerComputer = $d.TargetDomainName }
  }

For event 4740, the TargetDomainName field holds the caller computer, the machine that sent the bad password. Query the PDC emulator, which records every lockout in the domain. More examples:

# Privileged group changes in the last 7 days
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4728,4732,4756; StartTime=(Get-Date).AddDays(-7)} |
  Select-Object TimeCreated, Id, Message
# Failed Kerberos pre-authentication for one user
Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4771] and EventData[Data[@Name='TargetUserName']='jsmith']]" -MaxEvents 50
# Accounts created today
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4720; StartTime=(Get-Date).Date}

Run these against every DC ((Get-ADDomainController -Filter *).HostName) or, better, against a central collector.

Forward events centrally

An Active Directory audit policy is only as useful as the events you keep. Events on individual DCs are easy to lose when a log rolls over, and an attacker with admin rights can clear them. Forward them with Windows Event Forwarding (WEF) or your SIEM’s agent:

1. On a collector server, run wecutil qc and create a source-initiated subscription for the Security log events you care about.
2. On the DCs, add NETWORK SERVICE to the built-in Event Log Readers group so the forwarding service can read the Security log.
3. In a GPO linked to the Domain Controllers OU, enable Computer Configuration » Policies » Administrative Templates » Windows Components » Event Forwarding » "Configure target Subscription Manager" with a value such as Server=http://wec01.contoso.com:5985/wsman/SubscriptionManager/WEC,Refresh=60.
4. Check the Forwarded Events log on the collector.

Forward selectively. Sending every 4769 from every DC can overwhelm a small collector; start with account management, group changes, lockouts, 4719 and 1102.

Verify it works

• gpresult /h C:\Temp\gp.html on a DC shows your audit GPO applied, with the subcategories under Advanced Audit Configuration.
• auditpol /get /category:* shows the expected Success and Failure values.
• Create and delete a test user, add it to a test group and lock it out with wrong passwords. You should see 4720, 4728 or 4732, 4740 and 4726 on the DC that processed each change (4740 also on the PDC emulator).
• Change the test user’s description; with the SACL in place, a 5136 event shows the old and new value.

Troubleshooting

Symptom	Cause	Fix
auditpol shows “No Auditing” despite the GPO	Force subcategory setting disabled, or GPO not linked to the DC OU	Enable the Security Option; check with gpresult
Legacy and advanced settings conflict	Both configured in different GPOs	Set legacy Audit Policy to Not Defined everywhere
No 5136 events	No SACL on the changed object	Add auditing entries on the OU or domain root
No 4624 for user sign-ins on DCs	Workstation logons are logged on workstations	Use 4768/4776 on DCs, or audit member computers
Security log only covers a few hours	Log too small	Increase maximum size and forward events
Settings revert after a few minutes	Changes made with auditpol overwritten by GPO	Make changes in the GPO

Roll back or undo

To remove the Active Directory audit policy, set each subcategory in the GPO back to unconfigured (untick Configure the following audit events) or unlink the GPO. Windows does not always revert the effective policy when a GPO disappears, so run auditpol /clear /y on a DC and then gpupdate /force to reapply whatever policy still applies. Keep the Force subcategory setting enabled.

Active Directory audit policy at a glance

Official documentation: Audit policy recommendations, Advanced security audit policy settings, auditpol set.

Related guides: AD Account Lockout Source: Easy Event 4740 Tracing · Audit and disable NTLM in Active Directory · File share auditing: find who deleted a file.

Frequently asked questions