sodcalculator

10 Tech How-To

Fix DS Referral LDAP Error 8235 0x202b

Guide 10-8907 · Updated · Step by step

This error appears when a Domain Controller (DC) tries to process an LDAP referral and fails, usually because the referral points to a server that is unreachable, has a name resolution problem, or holds a partition the client cannot access. The fix involves checking DNS, verifying the referral target, and ensuring replication is healthy. You will need administrative access to at least one DC and, ideally, the ability to open a command prompt as Administrator.

What You’ll Need

  • Administrator credentials on the domain controller or a member server where the error occurs.
  • Access to DNS management (usually via the DNS console or PowerShell).
  • Ability to run repadmin and nltest (built into Windows Server).
  • Network access to the target domain controller (test with ping or Test-NetConnection).

Step-by-Step

  1. Identify the exact source and target of the referral. Open Event Viewer on the DC showing the error. Navigate to Windows Logs > Directory Service. Look for event ID 8235 or related events with the code 0x202b. The event details usually list the LDAP referral URL (e.g., ldap://server2.domain.com/DC=Domain,DC=com). Note the target server name.
  2. Test basic connectivity to the target server. From the DC with the error, open Command Prompt as Administrator. Run ping <target-server-name>. If it fails, try ping <target-IP>. If the name fails but the IP works, it is a DNS problem. If both fail, check firewall rules and network routing.
  3. Verify DNS resolution for the target. Run nslookup <target-server-name>. Check that it returns the correct IP address. Also run nslookup <target-IP> to ensure reverse lookup works. If either fails, check the DNS zones on the authoritative DNS servers. Common issues: stale A records, missing reverse lookup zones, or the target DC not registering its own records.
  4. Force DNS registration on the target DC. On the target DC (the one being referred to), open Command Prompt as Administrator and run ipconfig /registerdns. Then run nltest /dsregdns to re-register the SRV records. Wait a few minutes for replication, then re-test from the source DC.
  5. Check replication health. On the source DC, run repadmin /replsummary. Look for any failures in the last 24 hours. If there are replication errors, address those first—referrals often fail because the target DC has not received the latest partition data. Run repadmin /syncall /AdeP to force replication.
  6. Verify the target server is actually a DC for that partition. Run repadmin /showrepl on the source DC and look for the naming context (partition) mentioned in the error. Confirm the target DC is listed as a replica for that partition. If not, the referral is misconfigured—check the msDS-NC-Replica-Locations attribute on the partition object in ADSI Edit.
  7. Check if the target server is online and the LDAP service is running. On the target DC, open Services.msc and verify the Active Directory Domain Services service is running. Also check that the LDAP port (389) is listening: run netstat -an | findstr :389 on the target. If not, restart the service.
  8. Test the referral manually with LDP or PowerShell. On the source DC, open PowerShell and run Get-ADDomainController -Discover -Service ADWS to see what servers are discovered. Then use Test-ComputerSecureChannel -Server <target> -Verbose to test the secure channel. If that fails, the Kerberos or NTLM authentication between the DCs is broken—check for time skew (run w32tm /stripchart /computer:<target>) and correct it if needed.
  9. Clear cached referrals. Sometimes the DC caches a bad referral. Restart the Netlogon service on the source DC (this is safe on a DC but will briefly interrupt authentication). Run net stop netlogon && net start netlogon. Then retry the operation that caused the error.
  10. If the error persists, check for lingering objects. Run repadmin /removelingeringobjects <target> <partition-DN> /advisory_mode on the source DC. This will show if the target DC has objects that should have been deleted. If it reports lingering objects, you may need to run it without advisory mode (after backing up the target DC).

Common Mistakes

  • Assuming DNS is fine just because the server can ping by IP. LDAP referrals rely on DNS names, not IPs. Always test both forward and reverse lookup.
  • Restarting the DC without checking replication. A reboot can temporarily fix a symptom but will not repair a broken replication topology.
  • Editing the referral URL manually. The referral is generated by the DC based on its knowledge of the partition. Do not try to force it via registry edits—this almost always makes things worse.
  • Ignoring time skew. If the DCs are more than 5 minutes apart, Kerberos authentication fails, and referrals will fail even if DNS and replication are perfect.
  • Only checking the source DC. The problem is often on the target DC (the one being referred to). Check its event logs and services too.

Tips

  • Use repadmin /showrepl /verbose to see the exact replication partner and last success time for each partition.
  • Keep DNS records clean. Enable scavenging on your DNS zones to automatically remove stale records.
  • Monitor the Directory Service event log on all DCs. Set up alerts for event ID 8235 so you catch this early.
  • If you have multiple sites, verify that the referral target is in the same site or that site links are configured correctly. Use nltest /dsgetsite to check the site of each DC.
  • Document your partition topology. Knowing which DCs hold which partitions (Domain, Configuration, Schema, and any Application partitions) makes troubleshooting much faster.

Troubleshooting

If the steps above do not resolve the error, try these additional checks:

  • Check the target DC’s own event log. Look for errors on the target that might explain why it is not responding to referrals—event IDs like 1925 (replication failure) or 1126 (DNS registration failure).
  • Use dcdiag /test:dns /v on both DCs. This runs a comprehensive DNS test and will pinpoint record issues, delegation problems, or root hints misconfiguration.
  • Verify that the target DC has the partition loaded. Run repadmin /showrepl <target> /all and look for the partition in question. If it is missing, the target may have been demoted or the partition was removed—check the Active Directory Sites and Services console.
  • Check for a broken trust or secure channel. Run netdom verify <target> /domain:yourdomain.com from the source DC. If it fails, you may need to reset the machine account password for the target DC using netdom resetpwd /server:<source> /userd:administrator /passwordd:*.
  • If the referral points to a server that no longer exists, you may have a stale msDS-NC-Replica-Locations attribute. Use ADSI Edit to navigate to the partition object (e.g., CN=Configuration,DC=domain,DC=com), find the msDS-NC-Replica-Locations attribute, and remove any references to the dead server. Then force replication.
  • As a last resort, reboot the target DC. This clears its local cache and forces it to re-register its DNS records. If the problem is a hung LDAP thread, a reboot often clears it. Do not reboot the source DC unless you have confirmed the target is healthy.

Frequently Asked Questions

Q: What does error 0x202b mean exactly?
A: 0x202b is the hex representation of decimal 8235. In LDAP terms, it means the referral was returned, but the client could not connect to any of the servers listed in the referral. It is a network or DNS issue, not a permission problem.

Q: Can this error happen on a read-only domain controller (RODC)?
A: Yes. RODCs also process referrals, but they have a different replication model. Check that the RODC has a password replication policy that allows it to authenticate to the full DC it refers to.

Q: Will changing the DNS server IP on the DC fix this?
A: Only if the DC is pointing to a DNS server that does not have the correct records. The fix is usually to correct the records on the existing DNS server, not to change the DC’s DNS settings. Always use the same DNS servers on all DCs.

Q: Is it safe to restart the Netlogon service on a DC?
A: Yes, but it will briefly interrupt authentication and group policy processing for clients connected to that DC. It is safe to do during a maintenance window. It clears cached referrals and forces a fresh discovery.

Q: How do I know which partition the referral is for?
A: The event log entry for event 8235 includes the LDAP DN (distinguished name) of the partition, such as DC=Domain,DC=com. You can also use repadmin /showrepl to list all partitions and their replicas.

Q: This error appears on a client machine, not a DC. What should I do?
A: On a client, the error usually means the client cannot reach the DC that the referral points to. Check the client’s DNS settings (it should point to an internal DNS server), and test connectivity from the client to the DC on port 389 using Test-NetConnection <DC-name> -Port 389.

Related

General steps for current mainstream versions; menus can differ by device and version. See the disclaimer or report an error.

More in this bed

The whole Tech How-To bed →