Fix ERROR_DS_REFERRAL (0X0000202B) in Active Directory

Quick answer: Check DNS configuration on the client and the target DC. Make sure the client's primary DNS points to a DC that hosts the domain zone. Run nslookup for the target domain and verify the referral is to the correct DC. If DNS is clean, review AD Sites and Services for misconfigured subnet-to-site mappings or a broken site link bridge.

Why this happens

I've seen this error pop up in two common scenarios. First, when a client tries to bind to a domain controller but that DC's DNS returns a referral to another DC that's unreachable or doesn't host the requested partition. This usually happens after a site topology change—like when you add a new site but forget to update subnet mappings. The second scenario is simpler: the client's DNS server doesn't host the domain zone and returns a referral to a DC that can't be contacted because of a firewall or network issue.

The error 0X0000202B is technically an LDAP referral. Active Directory uses referrals to redirect clients to the right DC for their site or partition. When that referral fails, you get this error. It's not always a problem with the DC itself—it's often a configuration mismatch between DNS and site topology.

Fix steps

1. Check DNS on the client. Open a command prompt as administrator. Type nslookup yourdomain.com. If it fails or returns a server outside your domain's DNS, fix the client's DNS settings to point to a DC that hosts the _msdcs.yourdomain.com zone. I've seen this trip up people who set clients to use a public DNS like 8.8.8.8—don't do that for internal AD resolution.
2. Verify the referral target. Run nslookup -type=SRV _ldap._tcp.dc._msdcs.yourdomain.com. The response should list DCs that respond on port 389. If the referral points to a DC that's offline or not advertising LDAP, check that DC's service status.
3. Review AD Sites and Services. Open dssite.msc. Expand Sites, then Subnets. Make sure every subnet with clients maps to the correct site. A common mistake: the client's subnet is mapped to a site that has no DCs, forcing a referral to another site's DC that might be unreachable.
4. Check site links and cost. Right-click the Inter-Site Transports folder, then IP. Look at the site links. If the referral is going over a high-cost link or a link that's down, clients fail. Verify that site links have appropriate costs and are not set to ignore schedules.
5. Test with LDP.exe. Open LDP on the client. Connect to the DC that returned the referral. Then Bind. If you get the same error, the problem is specific to that connection—likely a permission or partition issue. Try connecting to a different DC to isolate.

Alternative fixes

If the above doesn't resolve the error, try these in order:

• Flush DNS and reset Netlogon. Run ipconfig /flushdns then nltest /dsregdns on the DC. This forces the DC to register its SRV records again. I've seen stale records cause referral loops.
• Disable strict name checking on the DC. This is rare, but if the referral is for a non-standard name, setting HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\DisableStrictNameChecking to 1 can help. Reboot after.
• Check firewall ports. Make sure UDP/TCP 389 (LDAP) and UDP 53 (DNS) are open between the client and the referral DC. A firewall change mid-day can break everything.

Prevention tip

Stop these errors before they happen. After any site topology change—new site, new subnet, new DC—run dcdiag /test:topology from any DC. It checks for broken referrals. Also, log DNS queries for _ldap._tcp.dc._msdcs for a week after changes. If you see referrals to unexpected DCs, fix the subnet-to-site mapping. One more thing: never use external DNS servers as primary for domain-joined machines. That caused this error more times than I can count.