Active Directory Referral Loop (0x00002043) Fixed

Cause #1: DNS SRV Records Pointing to a Dead or Wrong DC

This is the culprit in about 70% of cases. The client workstation or server gets a referral to a domain controller that doesn't exist, isn't responding, or isn't in the right site. The LDAP client follows the referral, hits another wrong DC, and loops until you see 0x00002043.

Start with nslookup — don't bother with anything else until you verify DNS.

nslookup -type=SRV _ldap._tcp.dc._msdcs.yourdomain.local

If the returned DC list includes old DCs that were decommissioned, orphaned, or have a different IP, that's your smoking gun. Also check site-specific records:

nslookup -type=SRV _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.yourdomain.local

Fix it: Open DNS Manager. Find the problematic SRV records under Forward Lookup Zones / yourdomain.local / _msdcs / dc / _tcp. Delete any records pointing to retired DCs. If the DC is dead but the record keeps reappearing, you need to demote that DC properly — or run ntdsutil metadata cleanup to remove its server object from Active Directory.

I've seen this happen after someone just turned off a DC without running dcpromo /demote (or the newer Remove-ADDomainController PowerShell command). The DNS scavenging eventually handles it, but that might take 7 days by default. Don't wait — manually delete the stale records.

Cause #2: Stale or Wrong Site Topology (AD Sites and Services)

If DNS looks clean, next check your AD site topology. The client gets a referral based on its IP subnet → site mapping. If that mapping is wrong or missing, the client may be sent to a DC in a different site, which then refers it back to the original site — hence the loop.

Run this from an elevated PowerShell prompt on any DC:

Get-ADReplicationSite | Format-List Name,Subnets

Check that every subnet you actually use is assigned to a site. Missing subnets cause clients to fall back to Default-First-Site-Name, which might not have any DCs. Also verify that your site links have correct costs. I've seen a scenario where two DCs in different sites had a site link cost of 1, but the link was broken — the DCs couldn't talk to each other, but clients still got referrals to the unreachable DC. Set the cost to something reasonable (100 is standard for a single site).

Fix it: In AD Sites and Services, create subnet objects for any missing ranges. Assign them to the correct site. Check that at least one DC exists in each site. If a site legitimately has no DC, make sure the site link cost encourages clients to use a working DC.

Quick sanity check: From a client machine, run nltest /dsgetdc:yourdomain.local. If it returns a DC from the wrong site or errors out, your topology is broken. Fix the subnets.

Cause #3: Cross-Ref Object Corruption or Orphaned NTDS Settings

Less common but nasty. The crossRef objects in the configuration partition tell DCs about other domains in the forest. If one of these references a DC that no longer exists, you get loops. This usually happens in multi-domain forests.

Open ADSI Edit. Connect to the Configuration partition. Navigate to CN=Partitions,CN=Configuration,DC=yourdomain,DC=local. Look at each crossRef object. Check the msDS-SDReferenceDomain and nCName attributes. If you see a reference to a domain or DC that's gone, that's your problem.

Also check CN=Servers,CN=yourdomain,CN=Sites,CN=Configuration — look for NTDS Settings objects that reference a server GUID that no longer exists. Right-click and delete orphaned objects. This requires Domain Admin rights and a steady hand. Don't delete anything unless you're certain it's orphaned.

Fix it: For crossRef objects, I've had to manually edit them in ADSI Edit to remove stale references. Backup first. For orphaned NTDS Settings, just delete the object and let replication rebuild it on the next GC sync.

Quick-Reference Summary Table

One last thing: if you're still stuck after all that, check time sync. Kerberos failures can trigger referral loops too. Run w32tm /query /status on the DCs. If they're off by more than 5 minutes, fix your time source. But 90% of the time, it's DNS.