Configure Windows Advanced Audit Policy via GPO: Recommended Settings

Out of the box, Windows records far less than most administrators assume. Default audit settings leave entire event categories dark: process creations are not logged, many account management actions go unrecorded, and the events that do exist often lack the detail an investigation needs. The result shows up at the worst possible moment — during incident response, when the question "what did the attacker do on this machine?" is answered with an empty event log. A single well-designed GPO fixes this permanently, and it is the prerequisite for every SIEM detection rule you will ever write: you cannot alert on events that were never generated.

Use Advanced Audit Policy — and force it to win

• Configure auditing under Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration — the 50+ granular subcategories — never the nine legacy top-level categories, which are all-or-nothing and drown you in noise.
• Enable the safeguard setting Audit: Force audit policy subcategory settings to override audit policy category settings (under Security Options) so legacy category settings cannot silently overwrite your granular policy.
• Verify effective policy on endpoints with auditpol /get /category:* — GPO modeling shows intent, auditpol shows reality.

The subcategories that matter — recommended baseline

• Logon/Logoff: Logon (Success and Failure), Special Logon (Success — this generates 4672 for privileged logons), Account Lockout (Failure). On DCs, add Kerberos Authentication Service and Kerberos Service Ticket Operations (Success/Failure) — the raw material for detecting kerberoasting and ticket abuse.
• Account Management: all subcategories, Success and Failure — user/computer account creation, group membership changes (4728/4732/4756 for privileged group additions), and password resets (4724). These are among the highest-signal events in the entire log.
• Detailed Tracking: Process Creation (Success) — event 4688, the backbone of endpoint forensics. Pair it with the companion GPO setting Include command line in process creation events under Administrative Templates > System > Audit Process Creation; a 4688 without the command line tells you PowerShell ran, one with it tells you what it did.
• Policy Change & Privilege Use: Audit Policy Change and Authentication Policy Change (Success) so tampering with auditing itself is recorded; Sensitive Privilege Use (Success/Failure) selectively — it is valuable but verbose, so validate volume in a pilot.
• System: Security State Change, Security System Extension (service installs — 4697), and System Integrity. Event 1102 (audit log cleared) should page someone — legitimate admins almost never clear the Security log.
• Object Access: leave file/registry auditing off globally — it is SACL-driven and explosive in volume. Enable it surgically on specific high-value objects (e.g., a SACL on the DSRM registry key or sensitive file shares) where a detection use case exists.
• Directory Service (DCs only): Directory Service Changes (Success) records before/after values for AD object modifications (5136/5137) — essential for tracking who changed what in the directory.

Deployment structure

• Split the policy into two or three GPOs: a baseline for all machines, a DC-specific layer (Kerberos, Directory Service auditing) linked to the Domain Controllers OU, and optionally a member-server layer. Microsoft's audit policy recommendations document provides per-role tables — start from its "stronger recommendation" column and trim to your log budget.
• Size the Security log to match the new volume: 4688 events alone will overwhelm the default log size. Set the maximum log size via GPO (1 GB+ on workstations, several GB on servers/DCs is a common starting point) — but treat local retention only as a buffer.
• Forward events off-host — Windows Event Forwarding to a collector, or your SIEM agent — because logs that die with the compromised machine were never really logs. Which events to centralize and alert on is covered in the companion item on critical Event IDs.
• Pilot on a representative group for one to two weeks, measure events-per-second and log growth, tune the noisy subcategories, then roll out broadly.

Going further

• Enable PowerShell auditing alongside: Module Logging, Script Block Logging (event 4104), and transcription via GPO under Administrative Templates > Windows Components > Windows PowerShell — attacker tradecraft is disproportionately PowerShell-shaped.
• Consider Sysmon with a curated configuration for depth native auditing cannot reach (process ancestry, network connections per process, image loads). Treat it as a complement to, not a replacement for, the audit policy baseline.
• Re-audit quarterly: confirm the GPO still applies everywhere (auditpol spot checks), log sizes still fit actual volume, and new server roles inherit the correct layer.

This is quiet, foundational work with zero user impact and outsized payoff: every detection rule, every threat hunt, and every incident investigation you run afterward stands on the events this one GPO makes exist.