How to Configure Credential Guard on Windows Server 2022

Why Audit Active Directory Changes

Active Directory is the central trust authority for most Windows enterprise environments. Every privilege escalation, account takeover, lateral movement attempt, and persistence mechanism an attacker deploys will leave footprints in AD — if auditing is configured correctly. Without comprehensive AD change auditing, security teams are blind to account creation, group membership modifications, GPO changes, and password resets that may indicate a breach in progress.

Windows Server 2022 provides granular auditing through the Advanced Audit Policy, which supersedes the older basic audit policy and allows per-subcategory control. Combined with Windows Event Forwarding, SIEM integration, and tools like Microsoft Defender for Identity, AD auditing gives security teams the visibility needed to detect and respond to threats in real time.

Understanding Basic vs Advanced Audit Policy

The basic audit policy (nine categories in Local Security Policy) is a blunt instrument that generates excessive noise or insufficient detail. The Advanced Audit Policy, introduced with Windows Vista/Server 2008, breaks each basic category into multiple subcategories and provides significantly more control. On Windows Server 2022, always use the Advanced Audit Policy.

View the current advanced audit policy state:

auditpol /get /category:*

View a specific category:

auditpol /get /category:"Account Management"
auditpol /get /category:"DS Access"
auditpol /get /category:"Logon/Logoff"

The output shows each subcategory and whether Success, Failure, or both are being audited. The default state on a new DC is minimal — many critical subcategories are not enabled by default.

Configuring Advanced Audit Policy via secpol.msc

For a single domain controller, you can use the Local Security Policy snap-in. Run:

secpol.msc

Navigate to Security Settings > Advanced Audit Policy Configuration > Audit Policies. The categories relevant to AD auditing are:

• Account Management — user and group object creation, deletion, modification, and password changes
• DS Access — directory service access, changes, and replication
• Logon/Logoff — account logons, Kerberos ticket requests, logoff events
• Account Logon — Kerberos authentication and credential validation
• Privilege Use — sensitive and non-sensitive privilege use
• Object Access — access to SACL-protected objects
• Policy Change — audit policy changes, trust changes

Deploying Advanced Audit Policy via Group Policy

For production environments, deploy audit policy across all DCs via GPO. Create a GPO linked to the Domain Controllers OU:

Navigate to: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies

Recommended settings for comprehensive AD auditing:

Account Management:

auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Computer Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Security Group Management" /success:enable /failure:enable
auditpol /set /subcategory:"Distribution Group Management" /success:enable /failure:enable
auditpol /set /subcategory:"Application Group Management" /success:enable /failure:enable
auditpol /set /subcategory:"Other Account Management Events" /success:enable /failure:enable

DS Access:

auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable
auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable
auditpol /set /subcategory:"Directory Service Replication" /failure:enable
auditpol /set /subcategory:"Detailed Directory Service Replication" /failure:enable

Logon/Logoff:

auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Logoff" /success:enable
auditpol /set /subcategory:"Account Lockout" /success:enable /failure:enable
auditpol /set /subcategory:"Special Logon" /success:enable

Account Logon:

auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable
auditpol /set /subcategory:"Credential Validation" /success:enable /failure:enable

Policy Change:

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

Enabling Object-Level Auditing: SACLs on AD Objects

Directory Service Change events (Event ID 5136) are only generated when a SACL (System Access Control List) is configured on the AD object being modified. The default AD schema includes SACLs on many sensitive objects, but you should verify and extend coverage.

To configure auditing on AD objects system-wide via ADSI Edit, connect to the Default Naming Context, right-click the root of the domain (e.g., DC=corp,DC=example,DC=com), choose Properties > Security > Advanced > Auditing. Add an entry:

• Principal: Everyone
• Type: Success
• Applies to: Descendant User objects
• Permissions: Write all properties, Delete, Delete subtree, Change password, Reset password

Apply equivalent SACLs to Group objects, Computer objects, and GPO objects (in the Group Policy Objects container).

You can also configure this via PowerShell using the Set-ACL cmdlet with a SACL entry, though the AD-specific SACL syntax requires using the ActiveDirectorySecurity class:

$path = "AD:DC=corp,DC=example,DC=com"
$acl = Get-Acl -Path $path -Audit

$auditRule = New-Object System.DirectoryServices.ActiveDirectoryAuditRule(
    [System.Security.Principal.SecurityIdentifier]"S-1-1-0", # Everyone
    [System.DirectoryServices.ActiveDirectoryRights]::WriteProperty,
    [System.Security.AccessControl.AuditFlags]::Success,
    [System.DirectoryServices.ActiveDirectorySecurityInheritance]::Descendents,
    [System.Guid]::Empty  # All objects
)

$acl.AddAuditRule($auditRule)
Set-Acl -Path $path -AclObject $acl

Key Event IDs for Active Directory Monitoring

The following event IDs in the Security event log are the most critical for AD change auditing:

Account Management Events:

• 4720 — A user account was created
• 4722 — A user account was enabled
• 4723 — An attempt was made to change an account’s password (by the user)
• 4724 — An attempt was made to reset an account’s password (by an admin)
• 4725 — A user account was disabled
• 4726 — A user account was deleted
• 4728 — A member was added to a security-enabled global group
• 4729 — A member was removed from a security-enabled global group
• 4732 — A member was added to a security-enabled local group
• 4756 — A member was added to a security-enabled universal group
• 4740 — A user account was locked out
• 4767 — A user account was unlocked

Directory Service Change Events:

• 5136 — A directory service object was modified (old and new value logged)
• 5137 — A directory service object was created
• 5138 — A directory service object was undeleted (Recycle Bin restore)
• 5139 — A directory service object was moved
• 5141 — A directory service object was deleted

Logon and Privilege Events:

• 4624 — An account was successfully logged on (Type 2 = interactive, Type 3 = network, Type 10 = remote interactive)
• 4625 — An account failed to log on
• 4648 — A logon was attempted using explicit credentials (pass-the-hash indicator)
• 4672 — Special privileges assigned to new logon (admin-level logon)
• 4768 — A Kerberos authentication ticket (TGT) was requested
• 4769 — A Kerberos service ticket was requested
• 4771 — Kerberos pre-authentication failed

Query for specific event IDs with PowerShell:

# Find all account creation events in the last 24 hours
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4720
    StartTime = (Get-Date).AddHours(-24)
} | Select-Object TimeCreated, Message | Format-List

# Find group membership changes
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = @(4728, 4729, 4732, 4756)
    StartTime = (Get-Date).AddDays(-7)
} | ForEach-Object {
    $xml = [xml]$_.ToXml()
    [PSCustomObject]@{
        Time    = $_.TimeCreated
        EventId = $_.Id
        Account = $xml.Event.EventData.Data | Where-Object {$_.Name -eq "MemberName"} | Select-Object -ExpandProperty '#text'
        Group   = $xml.Event.EventData.Data | Where-Object {$_.Name -eq "GroupName"} | Select-Object -ExpandProperty '#text'
        Actor   = $xml.Event.EventData.Data | Where-Object {$_.Name -eq "SubjectUserName"} | Select-Object -ExpandProperty '#text'
    }
}

Auditing Subcategories with auditpol

Use auditpol to verify your policy is applied correctly after GPO refresh:

# Get all subcategories and their current state
auditpol /get /category:* /r | ConvertFrom-Csv | Format-Table "Subcategory", "Inclusion Setting", "Setting Value"

# Export current audit policy to a CSV for baseline documentation
auditpol /get /category:* /r > C:AuditBaseline_$(Get-Date -Format yyyyMMdd).csv

# Restore a saved baseline
auditpol /restore /file:C:AuditBaseline_20260517.csv

If you want to confirm the effective policy applied by GPO (not just the local policy):

gpresult /h C:GPReport.html /scope computer
gpresult /r /scope computer | findstr /i "audit"

Forwarding Security Events to a Central Collector

Storing events only on the DC is insufficient — a compromised DC means the attacker can clear logs. Use Windows Event Forwarding (WEF) to stream Security events to a centralized Windows Event Collector (WEC) server.

On the collector server, configure the Windows Event Collector service and create a subscription:

# On the collector, start the WEC service
wecutil qc /q

# Create a subscription for DC security events
wecutil cs C:ADSubscription.xml

Example subscription XML (ADSubscription.xml) that collects critical AD events from all DCs:

  AD-Changes
  SourceInitiated
  AD critical event collection from DCs
  true
  http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog
  Custom
  
    
      20
      300000
    
  
  
    <![CDATA[
    
      
        *[System[(EventID=4720 or EventID=4722 or EventID=4724 or EventID=4725 or EventID=4726 or EventID=4728 or EventID=4729 or EventID=4732 or EventID=4740 or EventID=4756 or EventID=5136 or EventID=5137 or EventID=5141)]]
      
    
    ]]>
  
  HTTP
  RenderedText
  
  ForwardedEvents
  O:NSG:NSD:(A;;GA;;;DC)

On each DC, configure it to send events to the collector via Group Policy:

# Via GPO: Computer Configuration > Administrative Templates > Windows Components
# > Event Forwarding > Configure target Subscription Manager
# Set to: Server=http://wecserver.corp.example.com:5985/wsman/SubscriptionManager/WEC,Refresh=60

AD Auditing with Microsoft Defender for Identity

Microsoft Defender for Identity (MDI, formerly Azure ATP) provides behavioral analytics and attack detection on top of raw AD audit events. It ingests LDAP traffic, DNS, Kerberos events, and NTLM events from domain controllers using a lightweight sensor installed on each DC.

Install the MDI sensor on a domain controller (requires .NET 4.7+ and internet access to the MDI workspace):

# Download the sensor installer from your Defender for Identity workspace
# Then install silently
Azure ATP sensor Setup.exe /quiet NetFrameworkCommandLineArguments="/q" `
  AccessKey=""

MDI requires specific audit policies to function correctly. Verify MDI-required audit settings:

auditpol /get /subcategory:"Directory Service Access"
auditpol /get /subcategory:"Directory Service Changes"
auditpol /get /subcategory:"Credential Validation"
auditpol /get /subcategory:"Kerberos Authentication Service"
auditpol /get /subcategory:"Kerberos Service Ticket Operations"

MDI detects attacks including: Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash, Golden Ticket forgery, DCSync attacks, skeleton key malware, LDAP reconnaissance, brute force against LDAP/Kerberos, and enumeration of AD sensitive groups. It generates alerts that appear in the Microsoft Defender portal with detailed investigation timelines.

Increasing the Security Event Log Size

With comprehensive AD auditing enabled, the Security event log will fill rapidly. Increase the maximum log size and set a retention policy to prevent overwriting critical events before they are forwarded:

# Set the Security log maximum size to 1 GB
wevtutil sl Security /ms:1073741824

# Or via PowerShell
Limit-EventLog -LogName Security -MaximumSize 1GB

# Verify
Get-WinEvent -ListLog Security | Select-Object LogName, MaximumSizeInBytes, IsEnabled

Via Group Policy: Computer Configuration > Policies > Windows Settings > Security Settings > Event Log — set Maximum security log size to 1048576 KB (1 GB) and set Retention method for security log to “Overwrite events as needed”.

A well-configured AD audit policy, deployed via GPO, combined with centralized event forwarding and modern threat detection tooling, transforms Active Directory from an opaque black box into a rich source of security telemetry. Every privileged action, every account modification, and every authentication anomaly becomes visible and actionable — the foundation of a defensible AD environment on Windows Server 2022.