Fix 0X0000051E: Can't Disable Windows Group

What's Happening?

You tried to disable a user group — probably in Local Users and Groups or via Group Policy — and Windows threw ERROR_CANT_DISABLE_MANDATORY. This is Windows telling you that the group is a built-in, mandatory group. Some groups like Everyone, Authenticated Users, or SYSTEM are baked into the OS. You can't disable them because the system relies on them for basic security and access control.

The exact code is 0X0000051E, and it maps to ERROR_CANT_DISABLE_MANDATORY. You'll usually see it when you try to disable a group through lusrmgr.msc (Local Users and Groups) or when you're scripting a change with net localgroup or PowerShell.

The culprit here is almost always trying to disable something like Everyone or Authenticated Users on a domain-joined machine or a fresh Windows 10/11 install. It's not a registry corruption or a permissions issue — it's by design.

Fix 1: Stop Trying to Disable the Group (30 seconds)

Before you waste time poking at the registry, check if you're hitting a group that's actually mandatory. Here's the quick test:

Open Command Prompt as Administrator.
Run net localgroup and look for groups that are built-in. Those are the ones Windows protects.
If you see Everyone, Authenticated Users, or CREATOR OWNER in the list, you're going to hit this error. These are special groups that you can't disable — period.

The fix here is to change your approach. Instead of disabling the group, remove the group from the resource's permissions, or adjust the group's memberships. For example, if you don't want Everyone to have access to a folder, remove it from the folder's ACL rather than trying to disable the group itself.

If you're trying to disable a group for security reasons, look into using a restricted group policy or a security group with limited membership. But you can't turn off the built-in groups themselves.

Fix 2: Use the Correct Tool — Group Policy (5 minutes)

If you're doing this because you want to enforce a security boundary, the right way is to use Local Security Policy or Group Policy Management on a domain. Don't mess with the group directly. Here's the proper route:

Press Win + R, type secpol.msc, and hit Enter. This opens the Local Security Policy editor.
Go to Local Policies → User Rights Assignment.
Look for the right that the group is used for — like Access this computer from the network or Log on as a batch job.
Right-click the policy, select Properties, and remove the mandatory group from the list. That effectively stops it from being used for that right, without trying to disable the group.

This works because you're not disabling the group — you're just removing its permission in the context where you don't want it. It's the same result without tripping the error.

If you're on a domain, you'd do the same thing via gpmc.msc on a Domain Controller, and then force a policy update with gpupdate /force on the affected machines. That's the clean way to handle this across multiple systems.

Fix 3: Advanced — Modify Group Attributes via PowerShell (15+ minutes)

Okay, I get it. You really need to disable the group because some app or script is insisting on it. You can force it, but you'll be fighting Windows the whole way. Here's the advanced workaround:

Open PowerShell as Administrator.
Check the group's current attributes:

Get-ADGroup -Identity "Everyone" -Properties * | Select Name, GroupType, ObjectClass

On a domain, groups have a GroupType attribute. The Everyone group is a special built-in, but in some cases you can clear its GROUP_TYPE_DISABLED flag by setting the GroupType property to a value that doesn't include the disabled flag. For example, on a domain controller:

Set-ADGroup -Identity "Everyone" -GroupType 'UniversalSecurityEnabled'

But if you're on a workgroup machine (not domain-joined), you'll need to use net localgroup or WMI. Here's the ugly workaround for local groups:

Backup the group's members and permissions to a text file.
Delete the group, then recreate it with a different SID. But you can't do that for built-in groups.
Alternatively, you can change the group's SidHistory to a dummy SID, but that's a security risk and I'd advise against it.

Honestly, this route is a rabbit hole. I've seen colleagues spend an afternoon doing this and still hit side effects like broken file share access or services that refuse to start. If you're here, step back and ask: Why do I need to disable this group? In 99% of cases, the answer is 'I want to restrict access,' and you can do that with a restrictive ACL or a policy.

If you absolutely must force it, you can try using sc.exe to stop the affected service and then alter the group via regedit, but that's beyond what I'd recommend. Instead, consider creating a custom group that excludes the mandatory group, and assign permissions to that instead.

Don't bother with changing the group type in the registry — it rarely helps and can blue-screen your machine if you break a dependency.

When to Call It Quits

If you've tried the first two fixes and you're still stuck, the problem isn't the group — it's your approach. Step back and rethink what you're trying to achieve. Windows has these mandatory groups for a reason: they're the backbone of its security model. Work with the system, not against it.

If you're still getting the error after applying a GPO or changing local policy, check the Event Viewer for errors (Under Windows Logs → System), and make sure you're actually running as an administrator. Sometimes a UAC prompt is silently blocking your changes.

In short: don't try to disable mandatory groups. Instead, remove their permissions where you don't want them. That's the fix that works every single time.