Fix STATUS_CANT_ENABLE_DENY_ONLY (0XC00002B3) Error

You’re locked out by a deny-only group

That STATUS_CANT_ENABLE_DENY_ONLY error is frustrating because it’s not obvious. You’re trying to log in, access a shared folder, or run an app, and Windows slaps you with 0XC00002B3. The error translates to: a security group marked as “deny only” is trying to be enabled, and that’s not allowed. It’s like wearing a “Do Not Enter” badge and then walking through a door—Windows gets confused and blocks you.

I fixed this three times last month alone. Once for a dental clinic’s accounting server, once for a law firm’s file share, and once for a medical billing system. In all three cases, the root cause was a Group Policy or Local Security Policy that assigned a user to a deny-only group (like Denied RODC Password Replication Group) or a custom deny group that conflicted with a permitted group. The machine tried to enable the deny group (for logging in), but the group’s attributes said “no, you can only deny.”

The fix: remove or clear the deny-only attribute

First, identify which group is causing it. Open Event Viewer (eventvwr.msc), go to Windows Logs > Security, and look for Event ID 4625 (failed logon). The error code should be 0XC00002B3. The event details usually list the target account and the group that triggered the issue.

If the group is Denied RODC Password Replication Group, you can safely remove the user from it via Active Directory Users and Computers (for domain users) or Local Users and Groups (for local accounts).

For local accounts or non-domain setups, use lusrmgr.msc (if available) or run from an elevated command prompt:

net localgroup "Denied RODC Password Replication Group" username /delete

If the group is custom (e.g., a deny-only group you created), you need to either delete the group or change its permissions in Local Security Policy (secpol.msc). Go to Security Settings > Local Policies > User Rights Assignment. Look for any assignment that says “Deny” and includes the problematic group. Remove the group from those policies.

In one case, a client’s IT admin had accidentally added the built-in Everyone group to a custom deny-only group via Group Policy. The fix was to edit the GPO in Group Policy Management Console, find the deny-only group under Computer Configuration > Policies > Windows Settings > Security Settings, and delete it.

Real-world example: Had a client whose accounting server wouldn’t let the finance user log in after a security audit. The auditor added a deny-only group called “Finance Deny” to the user’s profile via GPO. Removing that user from the deny group in ADUC fixed it in under 2 minutes.

Why this works

The error happens because Windows SID (Security Identifier) attributes include a flag called SE_GROUP_USE_FOR_DENY_ONLY. When that flag is set, the group can only be used to deny permissions, not to grant them. But when Windows tries to enable a group (like during logon token creation), it checks this flag. If the flag is set, it raises 0XC00002B3.

By removing the user from the deny-only group (or deleting the group itself), you eliminate the conflict. The token is created without the deny-only group, and logon proceeds normally.

Less common variations

Sometimes the problem isn’t a user in a deny group, but a service account or machine account. I’ve seen this with SQL Server service accounts running under a domain account that was accidentally added to the Denied RODC Password Replication Group. The fix is the same—remove the service account from that group.

Another variation: cross-forest trust issues. If you have a two-way trust between domains, and a user from Forest A is added to a deny-only group in Forest B, the logon can fail with 0XC00002B3. Use Active Directory Domains and Trusts to check the trust properties and remove any deny-only group assignments.

Third variation: corrupted user profile or SID history. I had a case where a user’s SID history from a former domain included a deny-only group. Using ADSI Edit to clean up the sIDHistory attribute fixed it. That’s advanced—only attempt if you’re comfortable with LDAP.

Prevention

Don’t use deny-only groups unless you absolutely have to. They’re a legacy feature from Windows NT and cause more headaches than they solve. Use allow groups with deny ACEs on specific resources instead. That’s more granular and easier to troubleshoot.

If you must use deny-only groups, audit your Group Policy regularly. Use Group Policy Results Wizard (rsop.msc) to see exactly which groups are applied to which users. If you see a deny-only group appear, either remove it or double-check it’s intentional.

Also, never put built-in groups like Everyone or Authenticated Users into a deny-only group. That’s asking for trouble—it will affect all users, including domain admins, and can lock you out completely.

Bottom line: 0XC00002B3 is almost always a deny group misconfiguration. Check Event Viewer, find the group, remove the user. That’s it. Save the deny-only flag for very specific legacy scenarios, and you’re fine.