How to Set Up Advanced Audit Policies on Windows Server 2025

How to Set Up Advanced Audit Policies on Windows Server 2025

Windows Server 2025 ships with a powerful auditing subsystem that, when properly configured, generates a detailed forensic trail of user activity, privilege use, object access, and policy changes. The key to unlocking its full potential is understanding the difference between the nine basic audit categories visible in the legacy Security Policy snap-in and the 53 Advanced Audit Policy subcategories available through the Advanced Audit Policy Configuration (AAPC) framework. While basic audit policies apply a broad “enable/disable” switch to entire categories, advanced audit policies give you surgical precision — you can enable success auditing for Logon events without enabling failure auditing for Logoff, for example. This tutorial walks you through configuring advanced audit policies using auditpol.exe, Group Policy, and Security Policy, covering the most important subcategories for a production Windows Server 2025 environment.

Prerequisites

• Windows Server 2025 with Administrator or Domain Administrator credentials
• PowerShell 5.1 or later, elevated
• Group Policy Management Console (for domain-wide deployment)
• Local Security Policy (secpol.msc) for standalone or local configuration
• Understanding of Windows Event IDs (4624, 4625, 4688, etc.)
• Adequate event log storage — advanced auditing can significantly increase log volume

Step 1: Understand Basic vs. Advanced Audit Policies

Windows has two overlapping audit policy systems. The basic system (nine categories) predates Vista and should not be used in modern environments because it can conflict with Advanced Audit Policy settings. The auditpol /get /option:CrashOnAuditFail family of switches and the GPO path Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration are the correct mechanisms for Windows Server 2025. Critically, mixing both basic and advanced policies on the same system produces unpredictable results — you must choose one approach and stick with it:

# Verify current audit policy state for all categories
auditpol /get /category:*

# Check whether the "legacy" basic policy is forcing overrides
# (If this is enabled, basic policies override advanced settings)
auditpol /get /option:CrashOnAuditFail
auditpol /get /option:FullPrivilegeAuditing
auditpol /get /option:AuditBaseObjects

# Disable "force basic audit policy" GPO setting if present
# GPO path: Computer ConfigurationWindows SettingsSecurity Settings
#           Local PoliciesSecurity Options
# Setting: "Audit: Force audit policy subcategory settings (Windows Vista or later)
#           to override audit policy category settings" → Enabled

# Via registry (ensures advanced policies take precedence)
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsa" `
    -Name "SCENoApplyLegacyAuditPolicy" -Value 1 -Type DWord

Write-Host "Advanced audit policy mode confirmed."

Step 2: Configure Logon and Logoff Auditing

Logon events are the most fundamental audit data for detecting unauthorized access. Event ID 4624 (successful logon) and 4625 (failed logon) are generated on the machine where the logon occurs. For domain accounts, 4768 (Kerberos TGT request) and 4771 (Kerberos pre-authentication failure) are generated on domain controllers:

# Logon/Logoff subcategories
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Logoff" /success:enable /failure:disable
auditpol /set /subcategory:"Account Lockout" /success:enable /failure:enable
auditpol /set /subcategory:"Special Logon" /success:enable /failure:disable
auditpol /set /subcategory:"Other Logon/Logoff Events" /success:enable /failure:enable

# Account Logon subcategories (on DCs for domain accounts)
auditpol /set /subcategory:"Credential Validation" /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable

# Verify logon-related subcategory settings
auditpol /get /category:"Logon/Logoff"
auditpol /get /category:"Account Logon"

Key events to monitor:

• 4624 — Successful logon (check Logon Type: 2=interactive, 3=network, 10=remote interactive)
• 4625 — Failed logon (check SubStatus for reason: 0xC000006A=wrong password, 0xC0000234=account locked)
• 4648 — Logon with explicit credentials (RunAs, lateral movement indicator)
• 4768/4771 — Kerberos TGT request / pre-auth failure (generated on DCs)

Step 3: Configure Object Access Auditing

Object access auditing captures who accessed which files, folders, and registry keys. Event ID 4663 records successful object access, but it only fires when a System Access Control List (SACL) is configured on the target object. Enabling the audit subcategory alone is not sufficient — you must also set SACLs:

# Enable Object Access subcategories
auditpol /set /subcategory:"File System" /success:enable /failure:enable
auditpol /set /subcategory:"Registry" /success:enable /failure:enable
auditpol /set /subcategory:"Kernel Object" /success:disable /failure:enable
auditpol /set /subcategory:"Handle Manipulation" /success:disable /failure:disable
auditpol /set /subcategory:"Other Object Access Events" /success:enable /failure:enable
auditpol /set /subcategory:"Removable Storage" /success:enable /failure:enable

# Configure a SACL on a sensitive directory via PowerShell
$sensitiveFolder = "C:Sensitive"
New-Item -Path $sensitiveFolder -ItemType Directory -Force

# Add Everyone: audit all access (success and failure)
$acl = Get-Acl -Path $sensitiveFolder
$auditRule = New-Object System.Security.AccessControl.FileSystemAuditRule(
    "Everyone",
    [System.Security.AccessControl.FileSystemRights]::FullControl,
    [System.Security.AccessControl.InheritanceFlags]"ContainerInherit,ObjectInherit",
    [System.Security.AccessControl.PropagationFlags]::None,
    [System.Security.AccessControl.AuditFlags]"Success,Failure"
)
$acl.AddAuditRule($auditRule)
Set-Acl -Path $sensitiveFolder -AclObject $acl

Write-Host "SACL configured on $sensitiveFolder"
(Get-Acl $sensitiveFolder).Audit | Format-List

Step 4: Enable Process Creation Auditing with Command Line Logging

Process creation auditing (Event ID 4688) records every process that starts on the system, which is one of the most valuable data sources for detecting malware execution, lateral movement, and privilege escalation. Windows Server 2025 supports capturing the full command line in 4688 events, which must be enabled separately via a second GPO or registry setting:

# Enable Process Creation and Termination auditing
auditpol /set /subcategory:"Process Creation" /success:enable /failure:disable
auditpol /set /subcategory:"Process Termination" /success:enable /failure:disable

# Enable command line capture in process creation events (4688)
# GPO path: Computer ConfigurationAdministrative TemplatesSystemAudit Process Creation
# Setting: "Include command line in process creation events" → Enabled

# Enable via registry
$auditRegPath = "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemAudit"
New-Item -Path $auditRegPath -Force | Out-Null
Set-ItemProperty -Path $auditRegPath `
    -Name "ProcessCreationIncludeCmdLine_Enabled" -Value 1 -Type DWord

# Verify the setting
Get-ItemProperty -Path $auditRegPath -Name "ProcessCreationIncludeCmdLine_Enabled"

# Test: generate a 4688 event and query it
Start-Process -FilePath "cmd.exe" -ArgumentList "/c hostname" -Wait -WindowStyle Hidden

Start-Sleep -Seconds 2
Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4688]]" -MaxEvents 5 |
    Select-Object TimeCreated, Message | Format-List

Step 5: Configure Privilege Use Auditing

Sensitive privilege use (Event ID 4673) fires when a process uses a privileged right such as SeDebugPrivilege, SeTcbPrivilege, or SeBackupPrivilege. This can be noisy in some environments but is critical for detecting privilege abuse:

# Enable Privilege Use subcategories
auditpol /set /subcategory:"Sensitive Privilege Use" /success:enable /failure:enable
auditpol /set /subcategory:"Non Sensitive Privilege Use" /success:disable /failure:disable
auditpol /set /subcategory:"Other Privilege Use Events" /success:disable /failure:enable

# Query recent 4673 events
Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4673]]" -MaxEvents 10 |
    Select-Object TimeCreated, @{N='User';E={$_.Properties[1].Value}},
                  @{N='Privilege';E={$_.Properties[6].Value}} |
    Format-Table -AutoSize

Step 6: Configure Policy Change Auditing

Policy change events detect modifications to the audit policy itself, authentication policy, and other sensitive configurations. Event ID 4719 (System audit policy was changed) is especially critical — it can indicate an attacker attempting to disable auditing to hide their tracks:

# Enable Policy Change subcategories
auditpol /set /subcategory:"Audit Policy Change" /success:enable /failure:enable
auditpol /set /subcategory:"Authentication Policy Change" /success:enable /failure:enable
auditpol /set /subcategory:"Authorization Policy Change" /success:enable /failure:enable
auditpol /set /subcategory:"MPSSVC Rule-Level Policy Change" /success:enable /failure:enable
auditpol /set /subcategory:"Filtering Platform Policy Change" /success:disable /failure:disable

# Monitor for 4719 events (audit policy changes)
Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4719]]" -MaxEvents 10 |
    Select-Object TimeCreated, Message | Format-List

Step 7: Audit Active Directory Objects

For domain controllers, auditing Active Directory object changes is critical. Event ID 5136 (directory service object was modified) and 4661 (a handle to an object was requested) require both the DS Access audit subcategory and appropriate SACLs on AD objects:

# Enable Directory Service auditing
auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable
auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable
auditpol /set /subcategory:"Directory Service Replication" /success:disable /failure:enable

# Enable auditing on the AdminSDHolder container (protects privileged groups)
# Run on a domain controller
Import-Module ActiveDirectory
$domain = Get-ADDomain
$adminSDHolder = "CN=AdminSDHolder,CN=System," + $domain.DistinguishedName

$acl = Get-Acl -Path "AD:$adminSDHolder"
$everyone = [System.Security.Principal.SecurityIdentifier]"S-1-1-0"
$auditRule = New-Object System.DirectoryServices.ActiveDirectoryAuditRule(
    $everyone,
    [System.DirectoryServices.ActiveDirectoryRights]::WriteProperty,
    [System.Security.AccessControl.AuditFlags]::Success,
    [System.DirectoryServices.ActiveDirectorySecurityInheritance]::All
)
$acl.AddAuditRule($auditRule)
Set-Acl -Path "AD:$adminSDHolder" -AclObject $acl

# Query for AD object modification events
Get-WinEvent -LogName "Security" -FilterXPath "*[System[EventID=5136]]" -MaxEvents 10 |
    Select-Object TimeCreated, Message | Format-List

Step 8: Export, Backup, and Apply Audit Policy via GPO

Once you have the desired audit policy configured locally, export it for documentation and GPO deployment across the domain:

# Export current audit policy to a CSV for documentation
auditpol /get /category:* /r > "C:AuditPolicycurrent_auditpol.csv"

# Export in binary format for LGPO import
auditpol /backup /file:"C:AuditPolicyauditpol_backup.csv"

# Restore from backup (useful after misconfiguration)
# auditpol /restore /file:"C:AuditPolicyauditpol_backup.csv"

# Apply via LGPO.exe to distribute through GPO
# First place the backup CSV in the GPO's machine audit folder
$gpoDest = "C:GPOBackups{GUID}DomainSysvolGPOMachinemicrosoftwindows ntAudit"
New-Item -Path $gpoDest -ItemType Directory -Force
Copy-Item "C:AuditPolicyauditpol_backup.csv" -Destination "$gpoDestaudit.csv"

# Apply with LGPO
.LGPO.exe /g "C:GPOBackups{GUID}"

Write-Host "Audit policy deployed via LGPO"
auditpol /get /category:* | Measure-Object -Line | ForEach-Object { Write-Host "$($_.Lines) audit subcategory lines configured" }

Conclusion

Advanced Audit Policy Configuration transforms Windows Server 2025 into a rich source of forensic telemetry. By enabling the right combination of subcategories — Logon/Logoff, Credential Validation, Object Access with SACLs, Process Creation with command-line logging, Privilege Use, and Policy Change — and by configuring SACLs on sensitive AD objects and file system paths, you create a detailed, high-fidelity audit trail. Remember to size your Security event log appropriately (512 MB to 4 GB for busy servers), forward events to a SIEM or WEF collector, and periodically review which events are actually being generated to tune away noise while preserving the signals that matter most for your threat model.