Fix STATUS_NO_SUCH_GROUP (0xC0000066) on Windows

That login failure means Windows is looking for a group that no longer exists — usually after a domain user gets removed from a local group. Here's how to fix it.

Quick answer: Windows is trying to open a group by name (or SID) that's been deleted or renamed — usually a local group that a domain account still references. Re-add the group, or remove the stale SID from the account's token, and logon stops failing.

I know this error is infuriating because it doesn't show up until you try to log in or launch something that needs elevation, and then the whole session dies with a wall of hex. The status code itself is coming from the Windows kernel's object manager — it's saying "I was handed a group SID and there's nothing behind it." You'll see it in three main places: at the login screen after a bad GP refresh, inside Event Viewer as a 0xC0000066 logon failure, or splattered across a service startup log when a service account references a group that was cleaned up during an AD migration.

The most common real-world trigger I've dealt with: a junior admin removes a domain group from the local Administrators group on a workstation, but the user's cached profile still has that group in its access token. Next logon, the Local Security Authority tries to resolve the group name, gets nothing back, and bails. The same thing happens on domain controllers after you delete a global group that's still listed as a member of a built-in group like Backup Operators. GPO preferences love to leave these ghosts behind.

Step-by-step fix

Boot into Safe Mode with networking. You can't fix this from a normal session — the LSA will just keep throwing 0xC0000066 at every logon attempt. Hold Shift while clicking Restart, then Troubleshoot → Advanced options → Startup Settings → Restart → press 5. If a domain account is locked out, log in as a different local admin.
Open an elevated Command Prompt. From here we're going to list every local group and compare it to what Windows thinks should exist.
Enumerate your local groups. Run this and scan the output for anything obviously out of place — duplicated names, groups with the wrong SID prefix, or groups you know you deleted but are still listed:
```
net localgroup
```
On a healthy Windows 11 23H2 machine you'll see about 25-30 groups. If Users, Administrators, Guests, or Remote Desktop Users is missing, that's almost certainly your culprit.
Recreate the missing group. If Users got nuked (yes, people do this), rebuild it with the correct SID — the built-in Users group must be S-1-5-32-545 or half of Windows will refuse to start services:
```
net localgroup Users /add /comment:"Members of this group can access the computer"
```
Then re-add the standard members:
```
net localgroup Users "NT AUTHORITY\Authenticated Users" /add
net localgroup Users "NT AUTHORITY\INTERACTIVE" /add
```
Fix cached profile group memberships. Even after the group exists again, the broken token can linger. Log in as a different admin, then delete the offending user's profile folder under C:\Users\ after backing up their data. Windows rebuilds the profile on next logon with fresh group SIDs. This is heavy-handed — only do it if the group rebuild alone doesn't work.
Clear stale Group Policy. If the group lives in AD and the machine has a cached GPO referencing it, force a refresh from an elevated prompt:
```
gpupdate /force
rd /s /q C:\Windows\System32\GroupPolicy
```
Reboot immediately after — don't run anything else or Windows will partially recreate the policy folder in a weird state.
Verify with Event Viewer. Open eventvwr.msc, go to Windows Logs → Security, and filter for Event ID 4625. The failure reason should now show a normal bad-password entry rather than STATUS_NO_SUCH_GROUP. If it's gone, you're done.

If that doesn't work

Sometimes the group is fine and the SID itself is corrupt in the SAM database. This happens on machines that got restored from a disk image while joined to a domain, and the local SID got cloned. You'll need to rebuild the SAM entry:

net user Administrator /active:yes
shutdown /r /t 0

Log in as the built-in Administrator, then use lusrmgr.msc to inspect each group's SID. Any group with a SID that doesn't start with S-1-5-32- in a local context is a problem — delete and recreate it. Microsoft doesn't officially support editing the SAM directly, and third-party tools like chntpw work but can brick the install if you're sloppy. Take an image first.

On domain machines, the group might be gone from AD but still referenced by a GPO. Open Group Policy Management, run a Group Policy Results report against the affected user and computer, and look for references to SIDs that no longer resolve. Removed or notes groups show up with just a SID and no name. Delete those entries from the GPO preference and the error clears on next gpupdate.

Preventing it next time

Before you delete a group — local or domain — run a quick membership audit. On a workstation:

net localgroup | findstr /i "groupname"
wmic group where "Name='groupname'" get SID,Name

On AD, Get-ADGroupMember against the group before removal will show you what breaks. Nine out of ten 0xC0000066 cases I've seen came from someone deleting a group that was still in use, then spending an afternoon wondering why logons started failing on a Tuesday. The other one was a Windows Server 2016 box that got its SAM cloned from a 2012 R2 image during a migration — different problem, different fix, same error code.

One more thing: if this is showing up on a remote desktop host, check Remote Desktop Users first. That group gets deleted by overzealous security scripts more often than any other, and the symptom is always the same — RDP connects, then disconnects with 0xC0000066 in the security log.