Active Directory Audit Policy: The Complete Baseline Configuration for Security Monitoring
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Audit policy configuration is foundational -- every detection rule, every SIEM alert, every forensic investigation depends on the correct events being generated. Yet audit policy is one of the most commonly misconfigured elements in enterprise AD environments. Teams spend time building SIEM detection rules that never fire because the underlying audit subcategory was never enabled. This guide provides the complete baseline: which subcategories to enable, what Events IDs each generates, and how to verify the policy is actually applied.
Account Logon: Capture All Authentication
Account Logon captures authentication events at the authenticating domain controller. Enable: Credential Validation = Success, Failure (Event IDs 4776 -- NTLM authentication, 4768 -- Kerberos TGT, 4769 -- Kerberos service ticket, 4771 -- Kerberos pre-auth failure). These events fire on DCs and are the primary source for authentication attack detection. A password spray attack generates high volumes of Event 4776/4771 with failure codes. An ASREPRoasting attack generates Event 4768 with Pre-Authentication Type = 0. DCSync generates Event 4769 from a non-DC account with 1131f70... GUIDs. Kerberos Service Ticket Operations = Success, Failure (includes 4769). Kerberos Authentication Service = Success, Failure (includes 4768, 4771). These should all be enabled on DCs. The events fire at the authenticating DC, so ensure all DCs forward their Security logs to your SIEM -- if one DC is not forwarding, authentication attacks against accounts homed on that DC will not be detected.
Logon/Logoff: Track User Sessions
Logon/Logoff events fire on the machine being logged onto (member servers and workstations), not the DC. Enable: Logon = Success, Failure (Event ID 4624 -- successful logon with logon type indicating interactive/remote/network, 4625 -- failed logon). Logoff = Success (Event ID 4634, 4647 -- user initiated logoff). Special Logon = Success (Event ID 4672 -- logon with special privileges like SeDebugPrivilege, SeTcbPrivilege). Other Logon/Logoff Events = Success, Failure (Event ID 4648 -- explicit credential logon, used in pass-the-hash and lateral movement; Event ID 4649 -- replay attack detected; Event ID 4778 -- session reconnected). Account Lockout = Failure (Event ID 4740 -- account locked out, which DC generated the lockout). The logon type in Event 4624 is critical for analysis: Type 2 = interactive (console), Type 3 = network (SMB, etc.), Type 10 = RemoteInteractive (RDP), Type 9 = NewCredentials (RunAs, explicit credential). An attacker using pass-the-hash via SMB generates Type 3 logons.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Object Access: Directory Service and File Activity
Object Access covers AD directory service changes and file system access. For DCs: Directory Service Changes = Success (Event ID 5136 -- AD object attribute modified, 5137 -- object created, 5138 -- object undeleted, 5139 -- object moved, 5141 -- object deleted). These events fire when any AD object is created, modified, or deleted -- critical for detecting unauthorized account creation, group membership changes, GPO modifications, AdminSDHolder changes, and schema changes. Directory Service Access = Success (Event ID 4662 -- access to an object with specific rights -- primary source for DCSync detection, filtered for Replication GUIDs). Other Object Access Events = Success, Failure (Event ID 4698 -- scheduled task created, 4702 -- scheduled task modified, 4699 -- scheduled task deleted). For member servers and workstations (not DCs): File System = configurable per-folder via SACL settings -- enable only for specific sensitive directories (credential files, config files, security tool directories) to avoid excessive event volume.
Account Management and Privilege Use
Account Management tracks user and group changes. Enable all subcategories: User Account Management = Success, Failure (Event ID 4720 -- account created, 4722 -- enabled, 4723 -- password change attempt, 4724 -- password reset, 4725 -- account disabled, 4726 -- account deleted, 4738 -- user account changed). Security Group Management = Success (Event ID 4728 -- member added to global group, 4729 -- removed, 4732 -- added to local group, 4756 -- added to universal group). Computer Account Management = Success (Event ID 4741 -- created, 4742 -- changed -- critical for NoPac detection). Privilege Use: Sensitive Privilege Use = Success, Failure (Event ID 4673 -- privileged service called, 4674 -- operation on a privileged object, 4672 -- special privileges assigned at logon). SeDebugPrivilege use (4674) combined with LSASS access is a Mimikatz indicator. Token Right Adjusted = Success (Event ID 4703 -- token privilege adjustment, useful for UAC bypass detection).
Process Creation and Policy Changes
Process Creation is essential for detecting attack tooling. Enable: Detailed Tracking > Process Creation = Success (Event ID 4688 -- process created). Critically, also enable the GPO setting 'Include command line in process creation events' (Computer Configuration > Administrative Templates > System > Audit Process Creation > Include command line in process creation events = Enabled) -- without this, Event 4688 shows only the executable name, not the full command line arguments. With command line logging, 4688 reveals encoded PowerShell, LOLBAS abuse, and attacker tools. Process Termination = Success (4689). Note: 4688 with command line logging generates high event volumes on active systems -- Sysmon Event ID 1 (Process Create) is often preferred for process logging because it captures more context (parent process, hashes) with better filtering options. Policy Change: Audit Policy Change = Success (Event ID 4719 -- audit policy changed -- alert when audit policy is modified, which an attacker might do to disable logging). Authentication Policy Change = Success (Event ID 4706 -- new trust created, 4707 -- trust removed). System: Security System Extension = Success (Event ID 7045 -- service installed on the system, useful for detecting persistence via new services).
The bottom line
The audit policy baseline is the foundation everything else builds on. Verify the effective policy with auditpol /get /category:* and compare to the baseline above -- not what GPO intends to apply, but what is actually active. The most commonly missing subcategories in real environments: Directory Service Changes (misses all AD object modifications), Process Creation with command line (misses attack command visibility), and Kerberos Service Ticket Operations on DCs (misses Kerberoasting and DCSync detection). Fix these first, then work through the complete baseline.
Frequently asked questions
Should I enable audit Success, Failure, or both for each subcategory?
It depends on the subcategory and the monitoring goal. For authentication: enable both Success and Failure to see both successful attacks (pass-the-hash success = Success event) and failed attacks (password spray = Failure events). For directory service changes: Success only -- failures on AD object modification are unusual and add noise. For process creation: Success only -- you want all process starts, not just failed ones. For privilege use: Success and Failure -- failed privilege escalation attempts are also worth detecting. For logon: Success and Failure -- both are valuable. When in doubt, enable both and tune down the noise at the SIEM layer rather than not having the data.
What is the difference between basic audit policy and advanced audit policy?
Basic audit policy (9 categories like 'Account Logon', 'Object Access') is a coarse control that enables or disables entire event categories. Advanced Audit Policy (53 subcategories) provides granular control within each category. For example, basic 'Account Logon' success enables all account logon events; advanced policy lets you enable only Credential Validation and Kerberos Authentication Service individually. Microsoft recommends using Advanced Audit Policy exclusively. The GPO setting 'Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings' must be enabled to ensure Advanced Audit Policy takes precedence over the legacy basic settings.
Should I use Sysmon or rely on built-in audit policy for process monitoring?
Sysmon is generally preferred for process monitoring on workstations and member servers. Sysmon Event ID 1 captures process name, command line, parent process, process GUID, user, hashes (SHA1/SHA256), and more -- significantly richer than Event ID 4688. Sysmon also captures Event ID 3 (network connection), 7 (image loaded -- DLL loading), 8 (CreateRemoteThread -- injection indicator), and 10 (ProcessAccess -- LSASS access). Built-in Event ID 4688 with command line is a reasonable fallback when Sysmon cannot be deployed. On DCs specifically, the built-in audit policy is preferred over Sysmon for directory service changes (4662, 5136) as those events come from the AD engine, not process monitoring.
How much disk and network bandwidth does full audit logging consume?
On an active DC, the full audit policy recommended above typically generates 500 MB to 2 GB of Security event log data per day. On workstations, full auditing (especially with process creation + command line) generates 50 to 200 MB per day per active user. A 1,000-endpoint environment might generate 50 to 200 GB of raw audit data per day across all endpoints. Most SIEMs compress and index this to 10 to 30 GB ingested. Tune by being selective about which endpoints send process creation events to the SIEM (DCs and servers = always, workstations = selectively by risk tier) and by focusing file system auditing on specific sensitive paths rather than all file activity.
Why does auditpol /get sometimes show different settings than what I configured via Group Policy?
GPO audit policy settings propagate via Group Policy and are applied as per-computer settings at next Group Policy refresh. If you run auditpol /get immediately after making a GPO change, the effective setting may not yet reflect the GPO change. Wait for Group Policy refresh (run gpupdate /force to trigger immediately) and then re-check. A more common cause of discrepancy: a local security policy (secpol.msc or local GPO) overriding the domain GPO. Local security policy takes effect immediately and may override domain GPO audit settings if the 'Force audit policy subcategory settings' setting is not enabled. Check auditpol /get /category:* on the specific machine to see the enforced effective policy, not the intended GPO policy.
Which Active Directory audit events should be forwarded to a SIEM as high-priority detections versus stored only for forensic lookup?
High-priority, alert-on-every-occurrence events: Event ID 4720 (account created) outside of provisioning hours or by unexpected accounts, Event ID 4728/4756 (member added to privileged group), Event ID 4672 (special privileges assigned to new logon) for non-service accounts, Event ID 4698 (scheduled task created) with encoded PowerShell in the task action, Event ID 4662 with the DCSync GUID on non-DC accounts, and Event ID 5136 (directory service object modified) on Tier 0 AD objects. Forensic-only events (store but do not alert): Event ID 4624 Type 3 logons (volume is too high for per-event alerting -- alert instead on anomaly patterns like impossible travel), Event ID 4634/4647 (logoff), Event ID 4648 (explicit credential use) for expected service accounts, and Event ID 4688 (process creation) for standard application processes. The test for alert tier: if a single occurrence of this event from any source is always suspicious, it belongs in the alert tier. If a single occurrence is normal but the volume or combination with another event is suspicious, it belongs in forensic storage with anomaly detection rules.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.