Fix ERROR_DS_CANT_RETRIEVE_DN (0x000020D5) – Active Directory DN read failure

1. Stale LDAP referral – the most common culprit

I know this error makes you want to throw your keyboard. I've been there. The 0x000020D5 error, ERROR_DS_CANT_RETRIEVE_DN, almost always pops up when a domain controller tries to follow an LDAP referral to another DC and that referral is dead or misconfigured.

This happens a lot after you demote a domain controller but its referrals linger in other DCs' caches. You'll see this error in event logs or when running repadmin /showrepl or an LDAP query against a specific object.

How to check for stale referrals

Open Command Prompt as Administrator on the DC that threw the error. Run this:

repadmin /showrepl * /csv > c:\repadmin.csv

Open that CSV. Look for any last success timestamps that are way old, or last failure entries with status 8453 (that's the decimal for 0x000020D5). The source DC in those rows is your stale referral holder.

The fix – clear the referral cache

Don't mess around with manual registry edits for this. Use ntdsutil:

ntdsutil
activate instance ntds
metadata cleanup
remove selected server <stale_dc_name>
quit
quit

Replace <stale_dc_name> with the DC from your repadmin output. This purges its metadata and referrals. Then force replication:

repadmin /syncall /AdeP

Test your LDAP query again. If the error's gone, you're done.

2. Corrupted or missing attribute in the directory

This one's trickier. Sometimes the distinguished name attribute itself (distinguishedName) gets corrupted on a specific object – usually a user or group you're trying to query or replicate. I've seen this on Windows Server 2016 and 2019 after a partial restore or a failed schema update.

The symptom: the error shows up only when you query one particular OU or object. Other queries work fine.

How to identify the bad object

Use LDP.exe (install it from Remote Server Administration Tools if it's not there). Open LDP, connect to your DC, bind as Domain Admin. Then go to Browse > Search. Set the Base DN to your domain root, filter to (objectClass=*), and check Attributes – enter distinguishedName. Run the search. If it throws the error for a specific object, note its DN.

Alternatively, use PowerShell:

Get-ADObject -Filter * -Properties distinguishedName -ErrorAction SilentlyContinue | Where-Object { $_.distinguishedName -eq $null }

That'll return objects where distinguishedName is missing or empty.

The fix – repai

If you found the object and it's not critical (like a test user), delete it. If it's important, you need to repair the attribute using ADSI Edit. Open ADSI Edit, connect to the Domain Naming Context, navigate to the object. Right-click the object, Properties. If distinguishedName is missing from the attribute list, you can't add it manually – that's read-only. Instead, export the object to an LDIF file, edit the distinguishedName line to be correct, and import it back. Here's a quick export/import:

ldifde -f badobject.ldf -d "CN=BadObject,OU=Users,DC=domain,DC=com" -p subtree
# Edit the file to fix or add the distinguishedName line
ldifde -i -f badobject.ldf

I'd also recommend running an authoritative restore of that object if you have a good backup, but that's a whole other article.

3. Insufficient permissions on the attribute

This one's less common but easy to miss. The account running the query might not have read access to the distinguishedName attribute on that object. Yes, even Domain Admins can hit this if someone messed with the default security descriptor.

I saw this once after a security team applied a restrictive Group Policy that modified the AdminSDHolder container. The error showed up for a few specific admin accounts.

How to check permissions

Open ADSI Edit. Navigate to the object giving you trouble. Right-click > Properties. Go to the Security tab. Click Advanced. Check the Effective Access tab. Enter the account that's running the query (like the LDAP bind account or SYSTEM). Click View effective access. Scroll down to Read distinguishedName. If it's not checked, you've found the issue.

The fix – restore default permissions

Don't manually add permissions unless you're absolutely sure. The real fix is to reset the security descriptor on the object. Use dsacls:

dsacls "CN=BadObject,OU=Users,DC=domain,DC=com" /reset

This restores the default inherited permissions. Then run:

dsacls "CN=BadObject,OU=Users,DC=domain,DC=com"

to verify that Everyone or Authenticated Users has read access to distinguishedName. If not, you may need to reapply the default security template. Run sdprop (Security Descriptor Propagation) to push the fix down:

sdprop -target "CN=BadObject,OU=Users,DC=domain,DC=com"

Wait for replication, then retest.

Quick-reference summary table

Start with cause #1 – that's where you'll win 80% of the time. If not, move to #2, then #3. Don't skip the diagnostic steps; guessing costs you hours.

This error is a pain, but it's almost always fixable without rebuilding a DC. Drop me a comment if you're still stuck – sometimes the devil's in the exact version, like Server 2012 R2 vs 2022.