STATUS_DS_SENSITIVE_GROUP_VIOLATION (0XC00002CD) Fix

What the Hell Is This Error?

You're trying to add a user or group to a protected AD group — Domain Admins, Enterprise Admins, Schema Admins, or any group with adminCount set to 1. The error says STATUS_DS_SENSITIVE_GROUP_VIOLATION (0XC00002CD) and the message is plain: Only an administrator can modify the membership list of an administrative group.

This happens because AD's AdminSDHolder object and the SDProp process periodically reset the ACLs on protected groups. If someone (or some script) tried to change permissions directly on the group, SDProp overwrites it. The fix is to either work within the existing permissions, or temporarily break the protection.

Here's the real deal: 90% of the time the fix is simpler than you think. Try the first step. If it fails, escalate.

Quick Fix (30 seconds) — Use AD Users and Computers as a Domain Admin

This sounds stupid obvious, but I've watched a junior try to add a user to Domain Admins while logged in as a regular user. The error is blunt because AD enforces the protection at the object level, not just the UI level.

1. Log into any domain-joined machine with a Domain Admin or Enterprise Admin account. Not a delegated admin. The actual DA account.
2. Open Active Directory Users and Computers (dsa.msc).
3. Right-click the protected group → Properties → Members tab.
4. Click Add, type the user/group name, click OK.

If it works, you're done. If it still throws 0XC00002CD, move to the moderate fix.

Moderate Fix (5 minutes) — PowerShell with Correct Credentials

Sometimes the ADUC interface is buggy or the group membership is cached. PowerShell talks directly to the DC via LDAP. Use Add-ADGroupMember with explicit credentials.

$cred = Get-Credential  # Enter DA credentials
Add-ADGroupMember -Identity "Domain Admins" -Members "CN=JohnDoe,OU=Users,DC=contoso,DC=com" -Credential $cred -Server DC01.contoso.com

If that works, the issue was cached credentials or a broken MMC snap-in. If it still fails, you'll see the same error because the AD schema itself is blocking you. That means the group's ACL is corrupted or SDProp is misconfigured.

Advanced Fix (15+ minutes) — Remove AdminSDHolder Protection Temporarily

This is the nuclear option. Only do this if you understand the risks: removing protection exposes the group to accidental deletion or modification by any tool that can edit ACLs. But sometimes the only way to fix a borked membership list is to strip the protection, fix it, then reapply.

Step 1: Identify the protected group

Groups with adminCount set to 1 are protected. Check with PowerShell:

Get-ADGroup "Domain Admins" -Properties adminCount | Select-Object Name, adminCount

If adminCount is 1, SDProp owns the ACL.

Step 2: Remove the protection (dangerous)

The cleanest way is to modify the group's security descriptor to remove the AdminSDHolder inheritance. Do NOT just delete the ACL. Instead, clear the adminCount attribute:

Set-ADGroup "Domain Admins" -Clear adminCount

This stops SDProp from resetting the ACL on the next cycle (usually 60 minutes). Immediately modify the group membership — you have an hour to fix it.

Step 3: Actually add the user

Add-ADGroupMember -Identity "Domain Admins" -Members "CN=JohnDoe,OU=Users,DC=contoso,DC=com"

This should work now because the ACL isn't being overwritten.

Step 4: Reapply protection

After the change is made, set adminCount back to 1 to re-enable SDProp:

Set-ADGroup "Domain Admins" -Add @{adminCount=1}

Wait for SDProp to run (default: every 60 minutes on the domain controller with the PDC emulator role). You can force it with Invoke-ADDCReplication if you're impatient.

Heads up: If you skip step 4, the group is no longer protected. That means any user with delegated write access to that group can modify it. For production domains, that's a security risk. Don't leave it unprotected.

Why This Happens (The Boring Technical Bit)

Active Directory uses a mechanism called AdminSDHolder (short for Admin Security Descriptor Holder). It's an object under System\AdminSDHolder in the domain NC. The SDProp process runs every 60 minutes on the PDC emulator. It compares the ACLs of all protected groups (those with adminCount=1) against the AdminSDHolder template. If any ACL differs, SDProp overwrites it — including inherited permissions.

The error 0XC00002CD occurs when your user account does not have the Write Members permission on the group's ACL, AND the group is protected. Even if you're a Domain Admin, if someone messed with the ACL (removed the DA group from the ACL), you'll get this error. The quick fix usually works because a proper DA account still has Write Members by default. The moderate fix forces the authentication path. The advanced fix bypasses the protection entirely.

One More Thing: Check for Duplicate SIDs or Broken Inheritance

I've seen this error triggered by a corrupted ACL where the SYSTEM or Domain Admins SID was missing from the group's security descriptor. Use dsacls to peek at it:

dsacls "CN=Domain Admins,CN=Users,DC=contoso,DC=com"

Look for the line Allow DOMAIN\Domain Admins SPECIAL ACCESS for WRITE MEMBERS. If it's missing, you'll need to restore the default ACL. That's a separate rabbit hole — open a case with Microsoft if you're not comfortable rebuilding it manually.