Active Directory can't with account group memberships error 0X0000212D

You're in Active Directory Administrative Center (ADAC) or maybe the old ADUC snap-in, trying to add a user to a security group. You click OK, and bam — this error. The exact error code is 0X0000212D. The full text says something about "cannot perform this operation on a group with account group memberships." It's cryptic and frustrating.

I see this most often after a domain migration. Had a client last month who moved 200 users from a legacy 2008 R2 domain to a new 2019 domain using ADMT (Active Directory Migration Tool). Everything looked fine, but when we tried to add those migrated users to a local security group in the new domain, the error popped up. Every. Single. Time. The real trigger? The migration left behind SID history entries that made the new domain think the user still belonged to a group in the old domain.

What's actually causing this

Under the hood, this error means the directory service is confused. It sees that the user or computer account has a SID history attribute (sIDHistory) pointing back to a group in another domain. The new domain's domain controller tries to check group membership and hits a wall because that group doesn't exist locally, or the SID can't be resolved. Active Directory says "I can't update this group because you've got leftover memberships from somewhere else."

Three common root causes:

• SID history left over after migration — most common. Migration tools sometimes don't clean up properly.
• Group type mismatch — example: you're trying to add a user to a distribution group that's set as security-enabled but the user's SID history references a security group from the old domain. AD gets tangled.
• Replication delay — less common, but if you just changed group membership on another DC and it hasn't replicated, you get this error.

Fix it step by step

I've fixed this maybe a dozen times. Here's the order that works every time. Don't skip steps.

Step 1: Find the problem account

Open AD Users and Computers (dsa.msc). Find the user or computer that's giving the error. Right-click it and go to Properties. Look at the Attribute Editor tab — if you don't see it, enable Advanced Features under View menu.

Step 2: Check sIDHistory attribute

Scroll down to sIDHistory. If it has any values that's your problem. Each value is a SID from the old domain.

Step 3: Clean up the SID history

You can't do this from the GUI. You need ADSI Edit (adsiedit.msc).

1. Open ADSI Edit and connect to the domain partition.
2. Navigate to the user object (e.g., CN=JohnDoe,CN=Users,DC=newdomain,DC=com).
3. Right-click the object and choose Properties.
4. Find sIDHistory in the attribute list. Select each value and click Remove.
5. Click OK, close ADSI Edit.

Step 4: Force replication to all DCs

Open Command Prompt as admin on the DC you made the change on. Run:

repadmin /syncall /AdeP

This pushes the change across your domain controllers. Wait 30 seconds.

Step 5: Test the group membership again

Go back to ADUC or ADAC. Try adding that user to the security group. If it works, you're done. If not, go to Step 6.

Step 6: Check for group type mismatch

If step 1-4 didn't fix it, the issue might be the group itself. In ADUC, find the group you're trying to add the user to. Check its Properties under General tab. Make sure it's set to "Security" and not "Distribution." If it's a distribution group that has security enabled, it can still cause this error. Convert it to a universal security group using:

dsmod group "CN=GroupName,CN=Users,DC=newdomain,DC=com" -secgrp yes -scope u

If it still fails — check these three things

Sometimes the fix doesn't stick. Here's what I check next:

• SID filtering on trust — If you migrated between domains, the trust between them might have SID filtering enabled (it's on by default). That shouldn't cause this error, but if you have a broken trust, it can. Check trust properties.
• NTDS replication issues — Use repadmin /showrepl to verify all DCs are in sync. If one DC is stubborn, force replication or restart the KDC service on that DC.
• Corrupt user object — I've had one case where the user object itself was corrupt. I deleted it and re-created the account from scratch. Painful but fixed it.

One last thing: never use ADSI Edit to delete the user object itself unless you know what you're doing. Stick to cleaning sIDHistory. That's almost always the culprit.

If you're still stuck, post the exact error message and the output of repadmin /showrepl on a forum. But 90% of the time, cleaning sIDHistory is the magic bullet.