Fix ERROR_DS_CANT_RETRIEVE_SD (0x214e) in AD

Active Directory can't read a security descriptor on an object. Usually a permissions or replication issue. We'll walk through the fix from quick to thorough.

What’s causing 0x214e?

This error pops up when Active Directory tries to read the security descriptor (think of it as the object's permission rules) on a user, group, or computer object — and fails. The culprit here is almost always one of three things:

A corrupted security descriptor on the object itself.
Replication lag or a conflict between domain controllers.
Broken permissions on the NTDS Settings object in the Configuration partition.

I’ve seen this most often after a failed domain controller demotion or when someone manually mucked with AD permissions using ADSI Edit. It also shows up in mixed-OS environments (e.g., Windows Server 2016 talking to 2019) where SD flags aren't synced properly.

Step 1: The 30-second check — verify you’re not locked out

First, rule out dumb stuff. Can you read other objects from the same OU? Try opening the object’s properties in Active Directory Users and Computers (ADUC). If you get an “Access Denied” on that single object, the descriptor is likely borked. If you can’t read any objects in the domain, you’ve got broader permission issues — check your admin account’s group memberships.

Also run this from an elevated PowerShell prompt:

Get-ADUser -Filter * -Properties * -ErrorAction Stop

If that works, the problem’s specific to one object. Move to Step 2.

Step 2: The 5-minute fix — reset the security descriptor via ADSI Edit

This is where nine times out of ten you’ll land. You’re going to manually reset the security descriptor on the offending object. Here’s the play:

Open ADSI Edit (if it’s not installed, add it from Server Manager under Remote Server Administration Tools > AD DS and AD LDS Tools).
Right-click ADSI Edit in the left pane, choose Connect to. Leave the default naming context (Domain) — hit OK.
Navigate to the object that’s throwing 0x214e. For example: DC=yourdomain,DC=com -> CN=Users -> user object.
Right-click the object, go to Properties.
Find the attribute nTSecurityDescriptor — if it’s empty or shows an error, you’re in the right place.
Double-click it, and in the Security Descriptor field, paste this default SD for a user object (adjust the SID to match your domain’s admin SID):

O:BAG:BAD:AI(D;;0xf00ff;;;AU)(D;;0xf00ff;;;ED)(A;;0x1fffff;;;DA)(A;;0x1fffff;;;SY)

Replace the domain admin SID (DA) with your actual domain admins group SID. You can get that from Get-ADGroup "Domain Admins" | Select-Object SID.

Apply, refresh ADUC, and test. If the error’s gone, you’re done. If not, move to Step 3.

Step 3: The 15+ minute fix — check replication and repair the NTDS Settings SD

If resetting the object’s descriptor didn’t stick, the problem’s probably higher up — the security descriptor on the NTDS Settings object of a domain controller got corrupted or is out of sync. This is common after a failed DCPromo.

First, verify replication health:

repadmin /showrepl

Look for any “Last success” older than a few hours, or “Access denied” errors. If you see failures, run:

repadmin /syncall /AdeP

Now, for the real surgery — you’ll need to reset the SD on the NTDS Settings object under CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=yourdomain,DC=com.

Open ADSI Edit again, but this time connect to the Configuration naming context.
Navigate to the DC that owns the problematic object: CN=Servers -> CN=YourDC -> CN=NTDS Settings.
Check the nTSecurityDescriptor attribute on CN=NTDS Settings. If it’s missing or misconfigured, paste the default SD for a server object:

O:BAG:BAD:AI(D;;0xf00ff;;;AU)(D;;0xf00ff;;;ED)(A;;0x1fffff;;;DA)(A;;0x1fffff;;;SY)(A;;0x1fffff;;;CO)

Note the CO entry — that’s Creator Owner. Critical for the domain controller to manage its own settings.

After applying, force a full replication:

repadmin /syncall /AdeP /e

Wait 10 minutes, then test your original operation.

Step 4: Nuclear option — wipe and re-create the object

If none of that worked, the object’s metadata is likely irreparably hosed. You can use LDP.exe or dsrm to delete the object, then re-create it from scratch. This is last resort because you lose any linked attributes (passwords, group memberships).

Back up the object’s attributes first with Get-ADUser -Identity username -Properties * | Export-CliXml userbackup.xml.
Delete with Remove-ADUser -Identity username -Confirm:$false.
Re-create using New-ADUser and restore core attributes from the backup.

What about Samba or mixed environments?

If you’re running Samba 4 as a DC alongside Windows, you’ll see 0x214e when the SD flags don’t match Windows expectations. The fix is the same — reset the SD on the object using samba-tool:

samba-tool ntacl set "O:BAG:BAD:AI(D;;0xf00ff;;;AU)(A;;0x1fffff;;;DA)(A;;0x1fffff;;;SY)" --objectdn=CN=username,CN=Users,DC=yourdomain,DC=com

Then run samba-tool domain level show to ensure the functional level is consistent.

One more thing — don’t ignore event logs

Check the Directory Service event log on your DCs. You’ll usually see Event ID 1126 or 16653 alongside 0x214e. Those tell you which object and which DC is failing. Saves you guessing.

Bottom line — 0x214e is a permissions and replication headache, not a hardware failure. Start with the single object’s SD, escalate to the NTDS Settings object, and only nuke the object as a last resort. You’ll fix 98% of cases by Step 2.