Fix ERROR_DS_NO_CHAINING (0X00002087) in Active Directory

What this error actually means

You're seeing 0X00002087 when running an LDAP query or a tool like dsquery or ADSI Edit. The error text is ERROR_DS_NO_CHAINING – Chaining is not permitted. In plain English: a domain controller (DC) tried to refer your query to another DC, but the directory service blocked the referral because the msDS-EnableLDAPChaining setting isn't configured on the naming context.

This happens most often when you run a query that spans partitions (like searching across domains in a forest) or when a DC is running Windows Server 2016 or older and you're hitting a GC that's not fully replicated. I've seen it in hybrid environments where a 2008 R2 DC still hangs around and the schema version is old.

Don't panic. The fix is usually straightforward, but you need to work through it in order. Start with the simple stuff, then move up.

Step 1: The 30-second fix – Check DC connectivity and replication

Half the time, this error is a symptom of a DC that can't reach its replication partner. Before you touch any settings, run these commands on the DC that's throwing the error:

dcdiag /test:connectivity
dcdiag /test:replications

Look for any red text or FAIL in the output. If you see replication failures or a DC that's unreachable, fix that first. Chaining gets disallowed when a DC doesn't trust its own tree. Common culprits:

• DNS misconfiguration – the DC can't find other DCs by their _msdcs SRV records.
• Firewall rules blocking RPC (port 135 plus dynamic) between DCs.
• A recent crash that left the KCC (Knowledge Consistency Checker) in a bad state.

If replication is clean, restart the Net Logon service on the DC and try your query again. That clears temporary state without a full reboot:

net stop netlogon && net start netlogon

Still throwing the error? Move to the next step.

Step 2: The 5-minute fix – Enable chaining on the naming context

If connectivity is fine, the next thing to check is the msDS-EnableLDAPChaining attribute on the domain NC partition. This attribute controls whether the DC allows chained referrals across partitions. By default, it's not set for most partitions, which is fine for simple queries, but anything that spans domains trips it.

You can set it with ADSI Edit. Here's the deal:

1. Open ADSI Edit (install it via Server Manager if you haven't).
2. Connect to the Default Naming Context of your forest root domain.
3. Right-click the root object (e.g., DC=yourdomain,DC=com) and select Properties.
4. Scroll to msDS-EnableLDAPChaining. If it's not there, you need to add it (see note below). If it exists, set its value to TRUE.

If the attribute doesn't exist, you'll need to add it. That's a one-liner with PowerShell:

Set-ADObject -Identity "DC=yourdomain,DC=com" -Add @{msDS-EnableLDAPChaining='TRUE'}

But wait – this only works if the schema version on your DC supports that attribute. It was added in Windows Server 2008 schema (version 30). If you're still running 2003 or older, you're out of luck – upgrade first.

After setting it, wait for replication to complete (or force it with repadmin /syncall), then rerun your query. That solves it for most people.

Step 3: The 15+ minute fix – Update the schema or disable chaining entirely

If step 2 didn't help, you're looking at either a schema version mismatch or a group policy that's overriding the setting. Let's cover both.

3a. Update the AD schema

If you have a mix of DC versions, the schema master might be running an older schema. Check the schema version on your DCs:

Get-ADObject -Identity 'CN=Schema,CN=Configuration,DC=yourdomain,DC=com' -Property objectVersion

You need at least version 30 for chaining support. If it's lower, update the schema. That means running adprep from the installation media of your current Windows Server version. On Server 2019, it's:

adprep.exe /forestprep
adprep.exe /domainprep

Do this on the schema master, and make sure you're logged in with Enterprise Admin rights. This isn't a quick job – plan for 30 minutes of downtime for the schema changes to replicate.

3b. Disable chaining via the registry (the sledgehammer)

If you can't update the schema (say, you're stuck on a legacy app that requires old DCs), you can force the DC to ignore chaining restrictions. This is a registry tweak on each DC that needs to accept chained queries:

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Add a DWORD: Ldap-Chain-Enabled
Value: 1

After setting it, restart the AD DS service or reboot the DC. Be careful – disabling chaining can open up security holes if you have untrusted domains in your forest. I've only done this in lab environments or when a vendor app was legacy and the client didn't want to upgrade. Know the risk.

Pro tip: If you're using a third-party LDAP tool that triggers this, check if it supports the LDAP_SERVER_LAZY_COMMIT_OID control – sometimes that avoids the chaining issue altogether. But that's a developer-level fix, not a sysadmin one.

What if it still fails?

After the registry tweak, if the error persists, you're likely dealing with a corrupted AD database or a GC that's stuck in a partial replica state. Run ntdsutil integrity check:

ntdsutil
tdsutil: semantic database analysis

If it reports corruption, restore from backup or promote a new DC – that's the nuclear option, but sometimes you have to.

The bottom line: this error is almost always a configuration gap in chaining, not a hardware issue. Work the steps in order, and you'll kill it in under an hour.