STATUS_MEMBER_IN_GROUP 0xC0000067 Fix

When This Error Pops Up

You're in Active Directory Users and Computers, or maybe using a PowerShell script to bulk-add users to a security group. You click OK or hit Enter, and boom — the error STATUS_MEMBER_IN_GROUP (0xC0000067) stares back at you. The message says "The specified user account is already in the specified group account". Right. It's telling you what you're trying to do is already done. This tripped me up the first time I saw it, because I expected a more helpful error like "User is already a member".

The real trigger is almost always one of these:

• You're using a script or tool that doesn't check membership before adding.
• You're manually adding a user you forgot you already added (happens more than you'd think).
• Nested groups — the user is in a child group that's already a member of the target group.

Don't panic. It's not a corruption or permission problem. It's just a duplicate.

Root Cause

Under the hood, Windows checks the group's membership list before making a change. If the user's SID already appears in the member attribute of the group object, the operation fails with 0xC0000067. It's a safety feature — prevents duplicate entries that'd confuse tools and scripts later. The catch is that the error message isn't super clear, especially if you're adding via command line or API.

If the user is a member through a nested group (they're in Group A, Group A is in Group B, and you try to add them to Group B), you'll also get this. The system sees them as already present via inheritance.

Fix It in Three Steps

Step 1: Confirm the Membership

Open a command prompt as admin. Run this command, replacing GROUPNAME and USERNAME with the actual names:

net localgroup GROUPNAME | findstr /i USERNAME

If you see the username listed, you've confirmed the issue. If you're using Active Directory, you can also check via ADUC: right-click the group, go to Members tab, and look for the user.

Step 2: Remove the User from the Group

Since they're already a member, you need to remove them first. Use this command:

net localgroup GROUPNAME USERNAME /delete

If the user was added through nested groups, you can't remove them directly from the parent group — you'd need to remove them from the child group first, or exclude them if the tool supports it. But for direct membership, this command works fine.

Wait a few seconds for the change to replicate if you're in a domain environment. This is important — don't rush.

Step 3: Re-Add the User

Now add them back cleanly:

net localgroup GROUPNAME USERNAME /add

If you get 0xC0000067 again, something else is going on. Check for nested group membership using dsget user USERNAME -memberof or Get-ADGroupMember -Identity GROUPNAME | fl in PowerShell.

What to Check If It Still Fails

Here's where people get stuck. If the error persists after removal, try these:

• Nested groups: Run net group GROUPNAME /domain to list members. If you see other groups, check if the user is in those. You'll need to remove them from the child group, not the parent.
• Replication delay: In a multi-DC environment, changes take time. Wait 5 minutes and try again.
• Read-only DC (RODC): If you're connected to an RODC, you can't modify group membership directly. Connect to a writable DC.
• Group type: Distribution groups can't have security principals added. Make sure it's a security group if you're adding user accounts.

If none of that works, check the event log under Security for event ID 4728 or 4732 to see what's happening under the hood. Sometimes the error is misleading — it might actually be a permissions issue with a different user being added at the same time.

I've seen this error in Windows Server 2012 R2 through Windows Server 2022, and also on Windows 10/11 when using local groups. The fix is the same across the board. If you're using PowerShell, the Add-ADGroupMember cmdlet has a -Confirm flag that can help you avoid this in the future.

One last thing: if you're automating this, always check membership first. A simple if (-not (Get-ADGroupMember -Identity GROUPNAME).SamAccountName -contains USERNAME) in PowerShell saves you from hitting this error again.