0X000020E7

Active Directory Error 0X000020E7: Security Modify Fix

Cybersecurity & Malware Intermediate 👁 0 views 📅 Jun 9, 2026

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

  1. Open ADSI Edit (or use PowerShell). Connect to the Configuration partition.
  2. Navigate to: CN=Services,CN=Windows NT,CN=Configuration,DC=yourdomain,DC=com
  3. Find CN=AdminSDHolder under CN=System.
  4. Right-click properties, locate dSHeuristics attribute. If it's empty or missing, it means AdminSDHolder is using defaults. Setting it to 0000000001000 disables SDProp from overwriting permissions on user objects. Yes, it's weird — Microsoft never documented this well.
  5. Set it to that string, apply, then wait for SDProp or force it with Invoke-ADForestUpdate.
  6. 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

CauseSymptomFix
AdminSDHolder protectionError on protected group membersDisable AdminSDHolder temporarily or modify dSHeuristics
No ownership / broken ACLError on any object with unknown ownerTake ownership via ADSI Edit or Set-ADObject -Owner
Schema / attribute conflictError only on specific attributesVerify attributeGUID and class, adjust schema if needed

Was this solution helpful?