Fixing ERROR_ACCESS_AUDIT_BY_POLICY (0x00000311) on Windows Server

When This Error Pops Up

You're looking at a Windows Server's Security log — maybe a Domain Controller or a file server — and you see event ID 4907 with status code 0x00000311. The message reads: "Access to %1 is monitored by policy rule %2." This isn't a crash. It's an audit entry. But if you're seeing it hundreds of times a day, something's wrong.

The trigger is almost always a misconfigured System Access Control List (SACL) on a folder, file, registry key, or Active Directory object. Some admin — or a third-party tool — turned on auditing for "Everyone" or a broad group like "Domain Users." Every single access attempt, successful or not, gets logged. That's what you're seeing.

Root Cause

Windows has two layers of auditing: the old-school Audit Object Access policy and the newer Advanced Audit Policy under Security Settings > Advanced Audit Policy Configuration. The error 0x00000311 specifically means the audit was triggered by a policy rule — not by a manual SACL entry on the object itself. That rule could be from Group Policy or from a local audit policy.

The culprit is almost always a Global Object Access Audit setting in Group Policy. Someone configured a SACL at the domain level that applies to all file servers or all domain controllers. It's a blunt instrument. It catches everything.

How to Fix It

Step 1: Identify the Rule

1. Open the event that shows error 0x00000311 in Event Viewer.
2. Look at the Policy Rule ID in the details — it's a GUID.
3. Copy that GUID. Then run this on the affected machine (as admin):

auditpol /get /subcategory:"File System" /r

That shows you all file system audit rules. The GUID in the event should match one of the RuleId values in the output. If not, check the Registry and Active Directory subcategories too.

Step 2: Find the GPO or Local Policy

If the rule is coming from a domain GPO, open Group Policy Management Console on a DC. Go to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Object Access. Look for Audit File Share or Audit File System — those are the usual suspects.

Then check Global Object Access Auditing under the same node. That's the nuclear option. If it's configured, someone set a SACL that applies to every object on every machine that gets that policy. That's your problem.

Step 3: Narrow the Scope

Don't just disable the whole audit policy. That kills useful auditing too. Instead:

• Edit the GPO. Under Global Object Access Auditing, change the SACL from Everyone to a specific group like Domain Admins or a service account. Or remove it entirely if you don't need it.
• If the rule is on a single machine (not domain), run secpol.msc and go to Advanced Audit Policy Configuration > Object Access. Clear the global SACL there.

Step 4: Remove the SACL on the Object

Sometimes the policy rule is fine — the object itself has a SACL that's too broad. Right-click the folder or file, go to Properties > Security > Advanced. Check the Auditing tab. If you see an entry for Everyone with Full Control, remove it or change it to Write only.

Still Seeing the Error?

If you've checked all that and it's still logging, you might have a third-party security tool (like Carbon Black or CrowdStrike) that's injecting its own audit rules. Those tools often use the Windows audit subsystem. Check their documentation for how to mute specific audit events.

Also, run this to see a full list of all active audit policies on the machine:

auditpol /get /category:*

Look for any subcategory set to Success and Failure that shouldn't be. For example, Detailed File Share or Other Object Access Events can generate 0x00000311 if a SACL exists somewhere. Switch them to Success only or No Auditing if you don't need them.

One more thing — check the Security event log for event ID 4719. That logs every time an audit policy changes on the machine. If you see a change right before the errors started, you've found the culprit.