STATUS_MEMBER_IN_ALIAS (0XC0000153) — Account Already in Group Fix

It's annoying, I know.

You're running a script or clicking through Active Directory Users and Computers, trying to add a user to a security group—and Windows throws STATUS_MEMBER_IN_ALIAS (0XC0000153). The message says exactly what's wrong: the account is already a member of that group. But it's not always obvious why it thinks that.

The Direct Fix

The simplest path: remove the user from the group first, then re-add them. Here's how.

Using NET LOCALGROUP (local groups on a machine or domain controller)

net localgroup "YourGroupName" "DOMAIN\username" /delete
net localgroup "YourGroupName" "DOMAIN\username" /add

Run the delete even if you're not sure the user is in the group. If the delete fails with The specified account name is not a member of the group, that's fine—move on to the add. But in most cases with error 0xC0000153, the delete will succeed.

Using ADSI / PowerShell for Active Directory groups

Remove-ADGroupMember -Identity "YourGroupName" -Members "username" -Confirm:$false
Add-ADGroupMember -Identity "YourGroupName" -Members "username"

Same logic. Remove first, then add.

The reason step 3 works is that Active Directory and Windows local group management treat membership as a set operation: you can't add a member that's already present. What's actually happening here is the system is checking the member list before the write, and it finds a duplicate. Removing first clears that check.

Why This Happens in the First Place

The core cause is a membership conflict that's usually invisible. Common triggers:

• Primary group mismatch. In AD, every user has a primary group (usually Domain Users). If you try to add a user to a group that they're already a member of via nested group membership—say, they're in a distribution group that's also a security group—the flat membership check can fail. This is more common in mixed-mode environments.
• Stale cached membership. On a domain controller, the local SAM cache can hold an outdated copy of group membership. If you add a user, remove them via another tool, then try to add them again quickly, the cache hasn't synced. The fix: wait 5–10 seconds, or use net localgroup with explicit removal.
• Double-hop in scripts. When you run a PowerShell script that queries a remote DC, then tries to modify a group on that DC, the authentication context can have a lag. The script sees the user as not a member, but the DC disagrees. Using -ErrorAction SilentlyContinue on the remove avoids a crash.

This error is actually less common in pure Windows Server 2019+ environments—Microsoft improved the error messaging to be clearer. But in Server 2012 R2 and earlier, you'll see 0xC0000153 all the time with nested groups.

Less Common Variations of the Same Issue

Variation 1: The user is in the group via a foreign security principal

If you're in a multi-domain forest, a user from Domain A might be added to a group in Domain B via a foreign security principal (FSP). The FSP shows up as a different object. When you try to add the actual user object from Domain A, AD sees the SID as already present via the FSP. The fix isn't removal—it's adding the FSP instead, or removing the FSP first. Use Get-ADGroupMember to list all members and look for ForeignSecurityPrincipal objectClass.

Variation 2: Distribution group vs security group confusion

In Exchange hybrid environments, a group can have both a mail-enabled distribution list and a security group with the same name. If you try to add a user to the security group, but they're already in the distribution group, the error fires. The hidden detail: the DSID in the event log might show the user's Distinguished Name with a different group type. Check using Get-ADGroup -Identity "GroupName" -Properties groupType. The fix is to ensure you're modifying the correct group object.

Variation 3: The group itself is a member of another group (nesting)

You're trying to add a user to GroupA, but GroupA is a member of GroupB, and the user is already a member of GroupB. This is the most confusing one because the user isn't directly in GroupA. The system evaluates transitive membership during the add operation. The fix: remove the user from GroupB first, or restructure the nesting.

In each of these variations, the underlying truth is the same—the user's SID is already in the member list, just not where you're looking.

Prevention

Stop adding users to groups manually if you can avoid it. Use group-based provisioning tools that check for existing membership before adding. If you're writing scripts, always do a try/catch around the Add-ADGroupMember and handle 0xC0000153 by removing then retrying. Here's a pattern I use:

try {
    Add-ADGroupMember -Identity $group -Members $user -ErrorAction Stop
} catch [Microsoft.ActiveDirectory.Management.ADException] {
    if ($_.Exception.ErrorCode -eq 0xC0000153) {
        Remove-ADGroupMember -Identity $group -Members $user -Confirm:$false
        Add-ADGroupMember -Identity $group -Members $user
        Write-Host "Fixed duplicate membership for $user"
    } else {
        throw
    }
}

For domain controllers, keep the NTDS database clean—run repadmin /replsum regularly to spot replication issues that cause stale membership data. And if you're still on Windows Server 2008 R2 or 2012, upgrade. The newer group management code in Server 2016+ handles edge cases like nested foreign security principals much better.

The real fix is understanding that this error is a safety net, not a bug. The system is telling you, I already have that SID in the member list, and adding it again would be redundant. Respect that check, work around it cleanly, and move on.