ERROR_MEMBER_NOT_IN_ALIAS (0x00000561) — account not in group

When does this error show up?

You're on a Windows 10 Pro machine (or Server 2019) and you open Computer Management, go to Local Users and Groups, grab a user from the "Administrators" group, click Remove, and then get smacked with ERROR_MEMBER_NOT_IN_ALIAS (0x00000561). The user is sitting right there in the membership list, but Windows insists it's not a member.

This happens most often when you're dealing with a domain user that was added to a local group via Group Policy, or with a user that was removed from the domain but still shows in local group membership via cached SID lookups. I've also seen it after a domain migration where SID history gets confused.

What's actually happening here?

The short version: the user's SID (security identifier) isn't in the group's ACL anymore, but the UI still shows their name because of a cached translation. When you click remove, Windows tries to look up the SID in the group's membership list — and finds nothing. So it throws the error.

There are two common causes:

1. Cached SID mismatch — The user was removed from the domain, but their SID still exists in the local SAM database as a stale object. The UI resolves it to a display name via a cached lookup, but the actual membership is gone.
2. Nested group membership — The user isn't directly in that group. They're in another group that is a member. The UI flattens the view for convenience, but the actual membership is indirect.

The fix: remove the user from the command line

Skip the GUI — it's lying to you. Use net localgroup or Remove-LocalGroupMember in PowerShell. These tools let you work with the SID directly and bypass the cached name resolution.

Option 1: net localgroup (fastest)

Open an elevated command prompt (run as Administrator) and type:

net localgroup Administrators username /delete

Replace username with the actual SamAccountName (e.g., jdoe or DOMAIN\jdoe). If that still fails, you need to use the SID:

net localgroup Administrators S-1-5-21-... /delete

To find the SID, run:

wmic useraccount where name='username' get sid

Or in PowerShell:

Get-WmiObject Win32_UserAccount -Filter "Name='username'" | Select-Object SID

The reason this works: net localgroup reads the group's actual membership list from the SAM, not the cached display. It doesn't care if the SID resolves to a name or not.

Option 2: PowerShell (more control)

Remove-LocalGroupMember -Group "Administrators" -Member "username"

If username doesn't work, use the SID:

Remove-LocalGroupMember -Group "Administrators" -Member "S-1-5-21-..."

PowerShell will show a proper error if it's a nested group issue. In that case, you need to remove the source group, not the user.

Dealing with nested group membership

If the user is in, say, the Domain Users group, and Domain Users is in Administrators, you can't remove the user from Administrators directly. You have two choices:

• Remove Domain Users from the Administrators group (if that's acceptable).
• Remove the user from Domain Users at the domain level — but that's a domain admin task.

Check nested membership with:

net localgroup Administrators

Look for entries that are groups, not users. If you see something like Domain Users or BUILTIN\Users, that's your culprit.

If it still fails

Three checks:

1. Is the account actually deleted? Open lusrmgr.msc and see if the user still exists in the Users folder. If not, the SID is orphaned. You can remove the phantom entry by deleting the user object from the SAM registry key (dangerous — don't do this unless you're sure). Better: ignore the phantom entry in the group list — it's harmless.
2. Is the group protected? Windows protects built-in groups like Administrators from removing the last user. If you're trying to remove the only remaining member, you'll get a different error (0x00000538). This error specifically says the member isn't found — so that's not your issue here.
3. Check Group Policy — If the user is being added back automatically, a GPO is reapplying the membership. Run gpresult /h gp.html and look for Restricted Groups or Local Users and Groups policies. You'll need to modify the GPO to stop the re-add.