ANAVEM
Languagefr
Windows security monitoring dashboard displaying Event Viewer with security audit logs and policy configurations
Event ID 4933InformationMicrosoft-Windows-Security-AuditingWindows

Windows Event ID 4933 – Microsoft-Windows-Security-Auditing: Per-user audit policy table creation

Event ID 4933 fires when Windows creates a per-user audit policy table during system startup or when audit policies are modified. This security auditing event tracks the initialization of user-specific audit settings.

Emanuel DE ALMEIDAEmanuel DE ALMEIDA
18 March 20269 min read 0
Event ID 4933Microsoft-Windows-Security-Auditing 5 methods 9 min
Event Reference

What This Event Means

Event ID 4933 represents a critical component of Windows' advanced security auditing infrastructure. When this event fires, it signals that the operating system has successfully created or updated the per-user audit policy table, which serves as the foundation for user-specific security event logging.

The per-user audit policy table is a data structure maintained by the Local Security Authority Subsystem Service (LSASS) that maps individual user accounts to their specific audit policy settings. Unlike traditional system-wide audit policies that apply uniformly to all users, per-user policies allow administrators to configure different audit categories for different users or groups. For example, administrative accounts might have comprehensive auditing enabled while standard users have minimal auditing to reduce log volume.

This event becomes particularly significant in enterprise environments where compliance requirements demand detailed tracking of privileged user activities while maintaining system performance for regular users. The creation of the audit policy table ensures that subsequent security events will be properly categorized and logged according to the user-specific policies defined by administrators.

In modern Windows deployments, this event also indicates that the system is ready to process advanced audit policy configurations delivered through Group Policy. The timing of this event can be crucial for troubleshooting audit policy deployment issues, as it confirms that the underlying infrastructure is operational and ready to enforce the configured policies.

Applies to

Windows 10Windows 11Windows Server 2019/2022/2025
Analysis

Possible Causes

  • System startup and initialization of the Local Security Authority (LSA)
  • Group Policy refresh that includes per-user audit policy settings
  • Manual modification of local security audit policies through secpol.msc
  • Application of new audit policy configurations via auditpol.exe command
  • Service restart of the Local Security Authority Subsystem Service (LSASS)
  • Installation or configuration of security management software that modifies audit policies
  • Domain controller policy replication that includes per-user audit settings
  • System recovery operations that rebuild security policy databases
Resolution Methods

Troubleshooting Steps

01

Verify Event Details in Security Log

Start by examining the event details to understand the context and timing of the audit policy table creation.

  1. Open Event Viewer by pressing Win + R, typing eventvwr.msc, and pressing Enter
  2. Navigate to Windows LogsSecurity
  3. Filter for Event ID 4933 by right-clicking the Security log and selecting Filter Current Log
  4. Enter 4933 in the Event IDs field and click OK
  5. Double-click the most recent Event ID 4933 to view detailed information
  6. Note the timestamp, user context, and any additional details in the event description

Use PowerShell to query multiple instances:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4933} -MaxEvents 20 | Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap
Pro tip: Check the frequency of this event. It should typically appear during system startup or policy refresh cycles, not continuously.
02

Review Current Audit Policy Configuration

Examine the current per-user audit policy settings to understand what triggered the table creation.

  1. Open an elevated Command Prompt or PowerShell session
  2. Run the following command to display current audit policy settings:
auditpol /get /category:*
  1. To check per-user audit policies specifically:
auditpol /get /user:* /category:*
  1. Review Group Policy settings by opening gpedit.msc (Local Group Policy Editor)
  2. Navigate to Computer ConfigurationWindows SettingsSecurity SettingsAdvanced Audit Policy Configuration
  3. Check if any per-user audit policies are configured under Audit Policies
  4. Verify the Audit Policy Change subcategory is enabled to track future policy modifications
Warning: Modifying audit policies can significantly impact system performance and log volume. Always test changes in a non-production environment first.
03

Analyze Group Policy Application

Investigate whether Group Policy changes triggered the audit policy table creation.

  1. Check Group Policy application status:
gpresult /r /scope:computer
  1. Generate a detailed Group Policy report:
gpresult /h C:\temp\gpreport.html /scope:computer
  1. Open the generated HTML report and search for audit policy settings
  2. Check the Group Policy event log for policy application events:
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-GroupPolicy'} -MaxEvents 50 | Where-Object {$_.TimeCreated -gt (Get-Date).AddHours(-24)}
  1. Force a Group Policy refresh to test if the event recurs:
gpupdate /force
  1. Monitor the Security log for new Event ID 4933 entries after the policy refresh
  2. If in a domain environment, check domain controller event logs for policy replication issues
04

Investigate LSASS Service and Security Subsystem

Examine the Local Security Authority Subsystem Service and related components that manage audit policies.

  1. Check LSASS service status and recent restart events:
Get-Service -Name LSASS | Format-List *
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7034,7035,7036} | Where-Object {$_.Message -like '*LSASS*'} | Select-Object TimeCreated, Id, Message
  1. Review security subsystem initialization events:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4608,4609} -MaxEvents 10
  1. Check for security policy database corruption or rebuild events:
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Kernel-General'} | Where-Object {$_.Message -like '*security*'}
  1. Examine the security policy registry location for recent modifications:
Get-ItemProperty -Path "HKLM\SECURITY\Policy" -ErrorAction SilentlyContinue
Pro tip: The SECURITY registry hive is protected and may require special permissions to access. Use Process Monitor (ProcMon) to track file and registry access during policy initialization.
05

Advanced Troubleshooting with Audit Policy Tracing

Enable detailed tracing for audit policy operations to capture comprehensive diagnostic information.

  1. Enable audit policy debug logging by modifying the registry:
New-ItemProperty -Path "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" -Name "AuditBaseObjects" -Value 1 -PropertyType DWORD -Force
  1. Enable LSA audit and authentication logging:
auditpol /set /subcategory:"Authentication Policy Change" /success:enable /failure:enable
auditpol /set /subcategory:"Authorization Policy Change" /success:enable /failure:enable
  1. Use Windows Performance Toolkit (WPT) to trace security subsystem activity:
# Start ETW trace for LSA operations
wpr -start GeneralProfile -filemode
  1. Reproduce the issue by restarting the system or forcing a policy refresh
  2. Stop the trace and analyze:
wpr -stop C:\temp\lsa_trace.etl
  1. Use Event Tracing for Windows (ETW) to monitor real-time audit policy events:
# PowerShell script to monitor audit policy ETW events
$session = New-EtwTraceSession -Name "AuditPolicyTrace" -LogFileMode 0x8000100
Add-EtwTraceProvider -SessionName "AuditPolicyTrace" -Guid "{54849625-5478-4994-A5BA-3E3B0328C30D}" -Level 5
Start-EtwTraceSession -Name "AuditPolicyTrace"
Warning: ETW tracing can generate large amounts of data and impact system performance. Use only during active troubleshooting and stop traces when complete.

Overview

Event ID 4933 appears in the Security log when Windows creates or initializes a per-user audit policy table. This event fires during system startup when the Local Security Authority (LSA) establishes audit policy settings for individual users, or when audit policies are dynamically modified through Group Policy or local security policy changes.

The per-user audit policy feature allows administrators to configure different audit settings for specific users rather than applying system-wide audit policies. This granular control is particularly valuable in environments where different user roles require different levels of security monitoring. The event indicates that Windows has successfully established the audit policy framework for tracking user-specific security events.

This event is part of the advanced audit policy configuration introduced in Windows Vista and enhanced through subsequent versions. In Windows 11 and Server 2025, the per-user audit capabilities have been expanded to support more granular policy assignments and improved performance for large-scale deployments. The event typically appears shortly after system boot or when Group Policy refreshes occur.

Frequently Asked Questions

What does Event ID 4933 mean and when does it occur?+
Event ID 4933 indicates that Windows has created or initialized a per-user audit policy table. This event occurs during system startup when the Local Security Authority (LSA) establishes audit policy settings, during Group Policy refreshes that include audit policy changes, or when audit policies are manually modified. The event confirms that the system is ready to enforce user-specific audit policies rather than just system-wide settings.
Is Event ID 4933 a security concern or normal system behavior?+
Event ID 4933 is normal system behavior and not a security concern. It's an informational event that indicates proper functioning of the Windows audit policy infrastructure. However, if you see this event occurring frequently outside of normal startup or policy refresh cycles, it could indicate issues with Group Policy application, LSASS service instability, or unauthorized modifications to audit policies that warrant investigation.
How can I determine what triggered Event ID 4933 to appear?+
To determine the trigger, check the event timestamp against system startup times, Group Policy refresh cycles, and any recent audit policy modifications. Use 'gpresult /r' to check recent Group Policy applications, review the System log for service restart events around the same time, and examine Event ID 4719 (audit policy change) events that might have preceded the 4933 event. The event details may also include context about the specific user or process that initiated the policy table creation.
Can I disable Event ID 4933 if it's generating too many log entries?+
While you can disable this event by turning off the 'Audit Authentication Policy Change' subcategory using 'auditpol /set /subcategory:"Authentication Policy Change" /success:disable', this is not recommended in security-conscious environments. Instead, investigate why the event is occurring frequently. Normal systems should only generate this event during startup and occasional policy refreshes. Frequent occurrences may indicate underlying issues that need resolution rather than suppression.
What's the difference between per-user audit policies and system-wide audit policies?+
System-wide audit policies apply the same audit settings to all users on the system, while per-user audit policies allow different audit configurations for individual users or groups. Per-user policies provide granular control, enabling administrators to apply comprehensive auditing to privileged accounts while using minimal auditing for standard users to reduce log volume and improve performance. Event ID 4933 specifically relates to the initialization of the per-user audit policy infrastructure, which manages these user-specific settings.
Documentation

References (2)

Emanuel DE ALMEIDA
Written by

Emanuel DE ALMEIDA

Senior IT Journalist & Cloud Architect

Microsoft MCSA-certified Cloud Architect | Fortinet-focused. I modernize cloud, hybrid & on-prem infrastructure for reliability, security, performance and cost control - sharing field-tested ops & troubleshooting.

Discussion

Share your thoughts and insights

You must be logged in to comment.

Loading comments...