Fix ERROR_DS_AUDIT_FAILURE (0X000021B1) on Domain Controllers
This means your domain controller couldn't write an audit log for a requested operation. Usually it's a permissions or disk space issue, not a hardware failure.
The real fix: check the audit log location and permissions
You're banging your head because Active Directory operations just fail with this error, and nothing obvious in Event Viewer. Breathe. What's actually happening here is the Local Security Authority Subsystem Service (LSASS) can't create an audit record for whatever operation you're trying to do — like a password change, a group membership modification, or even a login. The operation fails silently, but the security log stays clean. Frustrating.
Skip the registry tweaks people recommend. 90% of the time this is a permissions or disk space issue on the audit log file. Here's the actual fix.
Step 1: Reset the audit policy to default
Open an elevated PowerShell prompt (Run as Administrator) and run:
auditpol /clearThis clears all audit policies and resets them to "No Auditing." Wait 30 seconds, then check if the error goes away. If it does, you found a corrupted or misconfigured audit policy. Reason: When audit policies get mangled — usually after a bad GPO push or a manual edit — LSASS gets confused and can't write the audit record, so it fails the operation instead of doing anything dangerous.
If the error persists, move to step 2.
Step 2: Check disk space and the security log size
Run this in PowerShell as Administrator:
wevtutil gl securityLook at maxSize and logFileName. The default max is 20 MB. If the log file path points to a drive with less than 100 MB free, that's your problem. LSASS needs room to write the audit entry. The reason step 1 didn't fix it is because the log file is full or the drive is out of space.
Fix it:
wevtutil sl security /ms:20971520
wevtutil cl securityThat sets max size to 20 MB and clears the log. If the error returns after a few days, increase the max size or move the log to another drive with more free space. The 0x21B1 error won't appear unless you're under 50 MB free on the drive hosting the security log.
Step 3: Verify NT AUTHORITY\SYSTEM has write permission on the log file
This is the one everyone misses. The default location for the security log is %SystemRoot%\System32\winevt\Logs\Security.evtx. Sometimes a security scan or a manual permission change can remove SYSTEM's write access. Check with:
icacls "C:\Windows\System32\winevt\Logs\Security.evtx"You should see NT AUTHORITY\SYSTEM:(R,W) in the output. If it's missing, run:
icacls "C:\Windows\System32\winevt\Logs" /grant "SYSTEM:(R,W)" /TThen restart the Windows Event Log service. The reason step 2 didn't work is because even with enough disk space, LSASS couldn't open the file for writing due to missing permissions. This happens often after someone applies a "least privilege" GPO without knowing the audit subsystem requirements.
Less common variations of the same issue
Group Policy Objects that override audit settings
If the error only happens in a specific OU, check the GPOs applied there. A GPO configured for "Success" auditing on a high-traffic event like Kerberos authentication can flood the log and trigger 0x21B1. The real fix isn't to disable auditing — it's to use auditpol /backup to save your current policy, then run auditpol /restore from a known-good backup. If you don't have a backup, create one:
auditpol /backup /file:C:\Backup\audit_policy.csvVolume shadow copy corruption
On Server 2016 and earlier, a corrupted VSS snapshot can block write access to %SystemRoot%. Reboot and run vssadmin list shadows. If you see anything older than 7 days, delete them all with vssadmin delete shadows /all /quiet. This is rare, but when it happens, it mimics the exact symptoms of 0x21B1.
How to prevent this from coming back
Set a scheduled task to monitor your security log's disk usage. Every hour, run a PowerShell script that checks free space on the drive holding the log and sends you an email if it drops below 500 MB. Here's a quick version:
$drive = (Get-Item C:\).PSDrive.Free / 1MB
if ($drive -lt 500) { Send-MailMessage -To admin@domain.com -From alerts@domain.com -Subject "Security log drive low on space" -Body "Only ${drive} MB free" -SmtpServer smtp.domain.com }Also, never manually edit the security log permissions. If you need to restrict access, use Group Policy to define who can read the log, but never remove SYSTEM's write access. That's the #1 cause I see in production environments.
One more thing: after a Windows Update that touches LSASS or security auditing, always run wevtutil gl security and auditpol /get /category:* to verify nothing changed. Updates can silently reset your audit settings to defaults, and the first failed operation will throw 0x21B1.
Was this solution helpful?