Fix ERROR_DS_SENSITIVE_GROUP_VIOLATION (0X00002139)

You ran into this error, and I get it — it's annoying when AD tells you you're not allowed to do something you clearly should be able to do.

The culprit here is almost always the adminSDHolder process. Active Directory has a built-in safety mechanism that protects privileged groups (Domain Admins, Enterprise Admins, Schema Admins, Administrators, etc.) from accidental or malicious changes. It does this by resetting the ACL on those group objects every 60 minutes to a template defined on the CN=AdminSDHolder,CN=System,DC=yourdomain,DC=com container. If someone (or something) changed the ACL directly on the group object instead of on the AdminSDHolder template, your change gets wiped out. That's the 0x00002139 error in a nutshell.

The Fix

Skip the GUI for this — you'll need ADSI Edit. Here's the exact sequence that works for me every time:

1. Open ADSI Edit (add it via Server Manager if not installed). Connect to the domain partition.
2. Navigate to CN=Users,DC=yourdomain,DC=com (or wherever the group lives).
3. Right-click the group that's throwing the error (e.g., Domain Admins), choose Properties.
4. Go to the Security tab. You'll probably see the owner is NT AUTHORITY\SYSTEM, and the permissions are grayed out.
5. Click Advanced → Change next to Owner. Change owner to your admin account (DOMAIN\youradmin) or Domain Admins group.
6. Check Replace owner on subcontainers and objects (not strictly necessary for a security group, but doesn't hurt).
7. Click OK. Now you can edit the ACL.
8. Add your admin account with Full Control (or at least Write Members). Make sure the permission is applied to This object only.
9. Click OK all the way out.

Now immediately add or remove members. You've got about 60 minutes before adminSDHolder runs again and resets the ACL back to the template. If you need the change to stick permanently, you need to modify the AdminSDHolder template itself.

# To modify the AdminSDHolder template permanently:
ADSI Edit -> CN=System -> CN=AdminSDHolder
Right-click Properties -> Security -> add your admin account with Full Control
# This will propagate to all protected groups on the next SDProp cycle (60 min).

Why This Works

The adminSDHolder process (SDProp) runs every 60 minutes on the PDC emulator. It compares the ACL of every protected group against the template stored on AdminSDHolder. If they differ, SDProp overwrites the group's ACL with the template. By taking ownership and adding yourself explicitly, you're overriding the template temporarily. To make it permanent, you change the template. That's the only way to stop the ACL from being reset. Changing the group's ACL directly is like patching a leaky pipe — it works until the pressure builds again.

Less Common Variations

Sometimes the error shows up not on group membership, but on delegation of control or GPO linking. Same root cause: the object is protected by adminSDHolder. The fix is identical. Another variation: you try to delete the group entirely and get the same error. Yep, adminSDHolder protects the group object itself from deletion. You'd need to either move the group out of the protected OU (like Users or Builtin) or remove the group from AdminSDHolder's scope — but that's a domain-wide change, so think twice.

A rarer case: the error happens on a group you created yourself, that isn't in a protected OU. In that scenario, check if someone manually applied the adminCount attribute to the group. AD sets adminCount to 1 on any group that's been added to a protected group's membership list. Even after you remove the group from the protected group, adminCount stays 1, and SDProp keeps hammering it. Fix: set adminCount back to 0 using ADSI Edit, then reset the ACL to what you want.

Prevention

Stop modifying ACLs directly on protected groups. If you need to grant permissions to manage them, change the AdminSDHolder template instead. That's the correct, supported way. Also, don't add random groups to Domain Admins — once a group has adminCount=1, it's forever in the crosshairs of SDProp. If you accidentally add a group, remove it, then manually clear adminCount via PowerShell:

Get-ADGroup "YourGroup" -Properties adminCount | Set-ADGroup -Clear adminCount

Finally, if you're automating AD changes with scripts, check the adminCount attribute beforehand and handle it explicitly. Saves you from waking up to a 2 AM call.