Fix ERROR_DS_NAME_ERROR_TRUST_REFERRAL (0X00002187) Fast
Active Directory can't resolve a name because a trust referral points to another forest you're not connected to. Jump to the fix: check DNS and trust configuration.
This error is infuriating — you're trying to resolve a name across a trust, and Active Directory basically says "I know where it is, but I'm not telling you." Let's fix it fast.
The One Fix That Works 9 Times Out of 10
Open DNS Manager on the domain controller where the error occurs. Go to the property page for your domain's zone — usually the forward lookup zone matching your Active Directory domain name. Look at the Name Servers tab. If you see any stub zones or secondary zones for the remote forest that aren't being refreshed properly, delete them. But the real culprit? Conditional forwarders pointing to the wrong DNS servers.
Instead, configure a conditional forwarder for the remote forest's domain name — point it to a DNS server in that remote forest that's authoritative for its own domain. Not a stub zone. Not a secondary zone. A plain conditional forwarder. Here's the registry path that controls how this behaves, though you usually don't need to touch it:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Value: AllowSingleLabelDnsDomain = 1If the remote forest uses a single-label domain like "CORP" (bad practice but it happens), you'll need that key. Otherwise, skip it.
After setting the conditional forwarder, run from an elevated command prompt:
nltest /dsgetdc:remoteforest.local /force
nltest /dsgetforesttrustIf nltest returns the error 0X00002187, you've got a deeper trust configuration problem. But if it works, you're golden.
Why This Fix Works
Active Directory uses DNS to locate domain controllers in trusted forests. When you initiate a name resolution — like mapping a security principal's SID to a name, or resolving a group membership — the local DC queries DNS for the remote forest's _ldap._tcp.dc._msdcs.<domain> SRV record. If DNS can't find that record because the forwarder is wrong or missing, the DC returns this trust referral error. The conditional forwarder tells the local DNS server exactly where to ask, bypassing any broken stub zones or missing delegation.
Also check the Name Suffix Routing tab on the trust properties. If the remote forest doesn't route names to your forest's suffix, or vice versa, you'll get this error for name lookups. Right-click the trust in Active Directory Domains and Trusts, select Properties, then go to the Name Suffix Routing tab. Make sure both sides have the appropriate suffixes enabled.
Less Common Variations
- One-way trust failure: If you set up a one-way trust from Forest A to Forest B, but users in Forest B try to access resources in Forest A, you'll see this error. Solution: verify that Forest A's DNS can resolve Forest B's domain, and that the trust is actually one-way inbound/outbound as designed.
- Windows Server 2008 R2 with SID filtering: Older servers might filter SIDs from trusted domains. Check
netdom trust TrustingDomain /domain:TrustedDomain /quarantine— if quarantine is on, you may get this error for certain name lookups. Disable it only if you're sure the trust is secure. - Cross-forest trust with disjoint namespaces: If Forest A uses
corp.example.comand Forest B usesad.example.org, the DNS forwarder needs to handle both suffixes. Sometimes the_msdcssubdomain isn't forwarded properly. Add a conditional forwarder for_msdcs.remoteforest.localif the base domain forwarder fails.
Preventing This from Coming Back
Document all your conditional forwarders. Keep a checklist of every trust relationship and its DNS routing. When you promote a new domain controller, verify DNS delegation before you finish the promotion wizard. I've seen this error pop up months after a DC migration because someone removed the old DNS server from the forwarder list without updating the conditional forwarders.
Also run dcdiag /test:trusts /e periodically. It's not a perfect test, but it'll catch most trust referral issues before they cause production outages. If you're managing multiple forests, set up a scheduled task that runs nltest /dsgetdc:trusteddomain.local from each DC every morning. Automate the check, because your help desk will thank you when they don't have to call you at 2 AM.
Was this solution helpful?