0X000020A2

Fix ERROR_DS_SEC_DESC_INVALID (0X000020A2) - Security Descriptor Invalid

Cybersecurity & Malware Intermediate 👁 0 views 📅 May 26, 2026

Active Directory can't apply permissions because the security descriptor is corrupt. Fix by resetting the SD using ADSI Edit or repadmin.

Quick answer

Run repadmin /showobjmeta to find the object, then use repadmin /setattr with a known-good security descriptor from a backup or a sibling object.

What's going on here?

You're trying to change permissions on an Active Directory object — maybe a user, group, or OU — and you get error 0X000020A2 (ERROR_DS_SEC_DESC_INVALID). The security descriptor attached to that object is corrupt. That's the data structure that controls who can read, write, or modify the object. When it's broken, AD can't figure out what you're allowed to do, so it just blocks the operation.

This usually happens after a bad replication event, a failed script that tried to tweak permissions manually, or a rogue admin tool that wrote garbage into the nTSecurityDescriptor attribute. I've seen it most often on domain controllers after a failed DCPromo or a botched restore from backup.

The good news is you don't need to rebuild the whole domain. You just need to replace that corrupt security descriptor with a clean one.

Fix steps

  1. Find the broken object. Open Event Viewer on a domain controller, look under Directory Service logs for event ID 1126 or 1127. That will give you the distinguished name (DN) of the object — something like CN=JohnDoe,OU=Users,DC=contoso,DC=com. Write it down.
  2. Identify a good security descriptor. You need a reference object that has the same class (user, group, OU) and is in the same container. Pick a working object of the same type. For example, if the broken object is a user in the Users OU, grab another user from the same OU.
  3. Open ADSI Edit. Install the AD DS Remote Server Administration Tools if you haven't already. Open adsiedit.msc as Domain Admin. Right-click ADSI Edit in the left pane, choose Connect to, select Default naming context, click OK.
  4. Browse to the good object. In the tree, expand the domain, then the container where your good object lives. Right-click the good object, choose Properties.
  5. Copy the security descriptor. In the property editor, scroll to nTSecurityDescriptor. Double-click it. The value is a long hex string. Select it all, copy (Ctrl+C). Keep this window open for reference.
  6. Browse to the broken object. In the same ADSI Edit tree, find the broken object. Right-click, choose Properties.
  7. Paste the good security descriptor. Scroll to nTSecurityDescriptor, double-click it, paste (Ctrl+V) the hex string. Click OK, then click Apply. You should see a success message — no error. If you get an access denied, you're not a Domain Admin or the object is protected by AdminSDHolder.
  8. Test. Close ADSI Edit. Open Active Directory Users and Computers, try to modify the object. The error 0X000020A2 should be gone.

Alternative fixes

If you can't find a good object of the same type (e.g., the only broken object is a domain controller object), you can use repadmin to pull the security descriptor from another domain controller in the same site. On a working DC, run:

repadmin /showattr <working-DC-name> <DN-of-broken-object> /atts:nTSecurityDescriptor

That outputs the hex SD. Then on the broken DC (or any DC), apply it with:

repadmin /setattr <any-DC-name> <DN-of-broken-object> nTSecurityDescriptor::<hex-string>

If the object is protected by AdminSDHolder (like an admin account), you need to first disable AdminSDHolder by setting adminCount to 0 on the object, make the change, then re-enable it. Use ADSI Edit to clear adminCount, apply the SD, then set adminCount back to 1.

If replication is the root cause, make sure all DCs are in sync. Run repadmin /syncall /AdeP from an elevated command prompt. If replication fails, you may have deeper issues — check DNS, time sync, and firewall ports.

Prevention tips

Never manually edit nTSecurityDescriptor on AD objects unless you really know what you're doing. If you need to delegate permissions, use the Delegation of Control Wizard in Active Directory Users and Computers — it writes the correct SD every time.

Back up your domain controller system state regularly. If you do mess up a security descriptor, you can restore from backup instead of playing surgical games.

Monitor event ID 1126 and 1127 in Directory Service logs. If they start popping up, you've got a problem brewing. Don't wait — fix it before you need to rebuild the whole domain.

Was this solution helpful?