Fix STATUS_KDC_UNABLE_TO_REFER (0XC00002FC) in Windows Server
Kerberos can't generate a referral for the requested service. Usually a DNS or time sync issue between domain controllers. Here's how to fix it fast.
What triggers this error
You'll see STATUS_KDC_UNABLE_TO_REFER (0XC00002FC) when a client tries to authenticate to a service that doesn't exist in the local domain's Kerberos database. The KDC checks its own realm, doesn't find the service, and then tries to generate a referral to another domain. That referral generation fails. Common real-world trigger: a user in Domain A tries to access a file share in Domain B, but the DNS record for the file server in Domain B isn't reachable from Domain A's KDC.
30-second fix: Check DNS resolution on the failing client
This is the most common cause. The KDC can't find the target service's domain controller via DNS. On the client machine that shows the error, open a command prompt as administrator and run:
nslookup %userdnsdomain%
nslookup %logonserver%Replace %userdnsdomain% with the domain the service is in (e.g., corp.contoso.com). You should see at least one A record for a domain controller. If you get "Non-existent domain" or a timeout, your DNS settings are wrong. Quick fix: set the client's DNS server to point directly to a domain controller in the target domain. On the client, go to Network Settings > Change adapter options > right-click your adapter > Properties > Internet Protocol Version 4 (TCP/IPv4) > Properties. Change the preferred DNS server to the IP of a known domain controller in the target domain. Click OK, then close. Run ipconfig /flushdns from command prompt. Try the operation again. If it works, you're done.
5-minute fix: Time sync between domains
Kerberos is picky about time. If the client's clock is more than 5 minutes off from the target domain's KDC, referral generation fails. On the client machine, run:
w32tm /query /statusCheck the "Source" field. It should be a domain controller. If it's wrong or not syncing, run:
w32tm /config /syncfromflags:domhier /update
net stop w32time && net start w32time
w32tm /resyncWait 30 seconds, then run w32tm /query /status again and confirm the time is within 5 minutes of the target domain's time. A quick way to check: run net time \\<target-DC-IP> and compare it with your local clock. If they differ by more than 5 minutes, fix the time on the client. That alone often resolves the referral error.
15+ minute fix: Check SPNs and trust relationships
If DNS and time are fine, the issue is likely a missing or duplicate Service Principal Name (SPN) for the target service, or a broken trust between domains.
Step 1: Identify the failing service
On the client, run this to capture a Kerberos trace:
klist purge
klist get <service-principal-name>Replace <service-principal-name> with the SPN you're trying to reach (e.g., HTTP/fileserver.corp.contoso.com). If this command returns the same 0XC00002FC error, you've confirmed the SPN is at fault. If it succeeds, the issue might be intermittent or related to caching.
Step 2: Verify the SPN on the target server
On a domain controller in the target domain, run this as administrator:
setspn -Q <service-principal-name>Look for the output. You want to see exactly one entry for that SPN, pointing to the correct computer account. If you see multiple entries (duplicate SPN), or none, that's your problem. To fix a duplicate SPN:
setspn -D <service-principal-name> <wrong-computer-name>To add a missing SPN:
setspn -A <service-principal-name> <correct-computer-name>After fixing, run setspn -Q again to confirm only one entry exists.
Step 3: Validate the trust relationship (cross-domain only)
If this is a cross-domain scenario, the trust between the two domains might be broken. On a domain controller in the client's domain, run:
nltest /trusted_domainsYou should see the target domain listed. Then test the trust:
nltest /sc_verify:<target-domain-name>If the command returns Status = 5 0x5 ERROR_ACCESS_DENIED or any error, the trust is broken. You'll need to reset it. On a domain controller in the target domain, run:
netdom trust <client-domain-name> /domain:<target-domain-name> /reset /UserD:<admin> /PasswordD:*You'll be prompted for the admin password for the target domain. After the reset, run the nltest /sc_verify again. It should return Success.
Step 4: Flush Kerberos tickets and retry
On the client, run:
klist purge
ipconfig /flushdnsThen restart the failing application or service. Try the operation that gave you the error. If it still fails, reboot the client machine. That clears any stale Kerberos tickets from the session.
What if none of these work?
If you've done all three steps and still see the error, you're looking at a deeper infrastructure problem. Check event logs on the client for Event ID 7 or 11 from the Kerberos source. Look at the KDC event logs on the target domain's domain controller for Event ID 16 or 17. Those logs often give you the exact machine name or SPN that's failing. You can also enable Kerberos logging on the client by setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters and adding a DWORD value LogLevel set to 1. Then reproduce the error and check %SystemRoot%\Security\Logs\Kerberos.log. That log is verbose but it will tell you exactly which step of referral generation failed.
Real-world tip: I've seen this error most often when someone sets up a new file server with a CNAME record instead of an A record for the FQDN. CNAMEs don't work well with Kerberos. Always use an A record for the target server's name.
Was this solution helpful?