Active Directory Error 0X000020E7: Security Modify Fix
You tried to modify a protected AD object and got denied. The fix is usually taking ownership or fixing the SDProp timestamp.
Cause 1: You're Modifying a Protected AD Object (AdminSDHolder)
This is the most common reason you see 0X000020E7. Active Directory has a built-in safety mechanism called AdminSDHolder. Every 60 minutes (by default), a background process called SDProp runs and resets permissions on privileged accounts and groups — Domain Admins, Enterprise Admins, Schema Admins, and groups that are members of them. If you manually changed a permission or attribute on one of these objects between SDProp runs, the next run will undo your change. And if you try to make a change while SDProp is running, you get this error.
How to tell if this is your problem: Check if the object you're modifying is a member of a protected group. Run this in PowerShell:
Get-ADGroupMember -Identity "Domain Admins" | Select-Object Name, SamAccountName
If the object shows up, that's your culprit.
Fix: Disable AdminSDHolder Protection Temporarily
- Open ADSI Edit (or use PowerShell). Connect to the Configuration partition.
- Navigate to:
CN=Services,CN=Windows NT,CN=Configuration,DC=yourdomain,DC=com - Find
CN=AdminSDHolderunderCN=System. - Right-click properties, locate
dSHeuristicsattribute. If it's empty or missing, it means AdminSDHolder is using defaults. Setting it to0000000001000disables SDProp from overwriting permissions on user objects. Yes, it's weird — Microsoft never documented this well. - Set it to that string, apply, then wait for SDProp or force it with
Invoke-ADForestUpdate. - Make your change, then remove the value or set it back to null to re-enable protection.
Don't leave it disabled. That's a security risk. I've seen shops leave it off for weeks and then wonder why a junior admin accidentally deleted a service account.
Cause 2: You Don't Own the Object — Permission Inheritance Broken
Another frequent trigger: the object's ACL is jacked up. Maybe someone manually removed inheritance or changed ownership. When AD's security subsystem checks the modification request, it sees the owner isn't you or a group you're in, and it throws 0X000020E7 even if you're a Domain Admin. Happens a lot after migrations or when you restore objects from a backup with different SIDs.
Check: Right-click the object in AD Users and Computers, go to Security > Advanced > Owner. If you see a SID that doesn't resolve to a known account, or it says "Unable to display", that's your problem.
Fix: Take Ownership via ADSI Edit or PowerShell
You need to connect with Domain Admin rights. In ADSI Edit, right-click the object, go to Properties > Security > Advanced. You'll need to change the owner to Domain Admins (or yourself). Click OK, reapply your changes.
PowerShell version (faster):
Get-ADObject -Identity "CN=JohnDoe,CN=Users,DC=yourdomain,DC=com" | Set-ADObject -Owner "DOMAIN\Domain Admins"
Then try your original operation again. Nine times out of ten, that's all you needed.
Cause 3: Schema Update or Attribute Conflict (Less Common)
If you're modifying an attribute that's marked as system-only or system-may-contain on an object that shouldn't have it, AD will reject the change. This happens when you're extending the schema incorrectly or applying a third-party tool that adds attributes to the wrong class. I've seen it with Exchange and Lync/Skype for Business migrations where someone ran an old schema prep.
Symptom: The error occurs only on specific attributes, not all changes to the object.
Fix: Check the Attribute Definition
Open ADSI Edit, go to the Schema partition. Find the attribute you're trying to modify. Check its attributeSecurityGUID — if it's set to a GUID that matches a protected attribute set (like userAccountControl), you can't touch it unless you're a Schema Admin or follow specific procedures. If it's a custom attribute, verify the class it's linked to actually allows modifications.
For a quick workaround, you can temporarily give your account Schema Admins membership, make the change, then remove it. But that's a band-aid — you should fix the underlying schema object instead.
Quick-Reference Summary
| Cause | Symptom | Fix |
|---|---|---|
| AdminSDHolder protection | Error on protected group members | Disable AdminSDHolder temporarily or modify dSHeuristics |
| No ownership / broken ACL | Error on any object with unknown owner | Take ownership via ADSI Edit or Set-ADObject -Owner |
| Schema / attribute conflict | Error only on specific attributes | Verify attributeGUID and class, adjust schema if needed |
Was this solution helpful?