Fix STATUS_MAX_REFERRALS_EXCEEDED (0xC00002F4) in Windows

Kerberos ticket referral chain too long. Usually hits when a domain controller can't find the target domain and keeps hopping. Fix is DNS or trust config.

When This Error Hits

You'll see STATUS_MAX_REFERRALS_EXCEEDED (0xC00002F4) when a Windows machine (typically a domain-joined workstation or server) tries to authenticate to a resource — maybe a file share, SQL server, or web app — that's in a different Active Directory domain. The workstation talks to its local domain controller (DC), which then tries to refer it to a DC in the target domain. But something in that referral chain breaks. The DC starts bouncing referrals — it doesn't know where the target domain lives, so it keeps asking other DCs, each one passing the buck. Kerberos has a hard limit of 10 referrals in a chain. Once you hit that, you get 0xC00002F4.

I've seen this most often in multi-domain forests where someone misconfigured DNS or the trust path is broken. Another common trigger: a client with stale DNS records pointing to old DCs that no longer exist. Or a shortcut trust that's half-baked.

Root Cause in Plain English

Kerberos works like a phone tree — your local DC calls another DC, which calls another, until it finds one that can issue a ticket for the target service. Each hop is a referral. If the trail goes cold (bad DNS, missing SRV records, or a trust that's not fully set up), the DCs keep referring to each other in circles. After 10 hops, Kerberos gives up and throws 0xC00002F4. The culprit here is almost always DNS — specifically, the DC's SRV records for the target domain aren't reachable or are pointing at the wrong IPs.

Fix: Step-by-Step

Check DNS SRV records for the target domain.
On the client machine (or any domain member), run:
```
nslookup -type=SRV _kerberos._tcp.targetdomain.com
```
Replace targetdomain.com with the actual domain name you're failing to authenticate to. You should see at least one DC listed. If you get a "server failed" or no records, your DNS is broken. Also check _ldap._tcp.targetdomain.com — same deal.
Verify the client's DNS server points to a DC in its own domain.
Run ipconfig /all on the client. The primary DNS server should be a DC from the client's domain, not an external DNS or a random router. If it's wrong, change it in the NIC settings or via DHCP. Then flush DNS: ipconfig /flushdns.
Test the trust path (if cross-domain).
From a DC in the client's domain, run:
```
nltest /domain_trusts /all_trusts
```
Look for the target domain. If it's missing, the trust is broken. Recreate the trust from Active Directory Domains and Trusts. Be methodical — one-way trusts are common culprits.
Check for stale DC records in DNS.
Open the DNS console on a DC in the client's domain. Expand Forward Lookup Zones > clientdomain.com > _msdcs > dc > _tcp. Look for old DC entries that don't exist anymore. Delete them. Same for the target domain's zone if you manage it.
Increase Kerberos referral limit (last resort).
Only do this if you can't fix the DNS or trust path immediately and need a Band-Aid. On the client machine, add this registry key:
```
HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Value: MaxReferralCount
Type: DWORD
Data: 15 (decimal)
```
Then reboot. Default is 10. Don't go above 15 — you'll hit performance issues.

If It Still Fails

First, grab a Kerberos trace. On the client, run klist purge to clear cached tickets, then reproduce the error. Run netlogon /repair on the client to reset the secure channel. If you're still stuck, check the event logs on the client and the local DC — look for Event ID 11 from Kerberos or 4000 from NETLOGON. They'll tell you the exact referral path that broke. Also verify that the client's time is synced to the domain — Kerberos is picky about clock skew (max 5 minutes).

My rule of thumb: 90% of 0xC00002F4 cases are DNS SRV records. Fix those first. Don't touch the registry unless you're absolutely sure DNS and trusts are clean.