Fix SEC_E_KDC_UNABLE_TO_REFER (0x80090341) in Windows

When This Error Shows Up

You're trying to connect to a service—maybe SQL Server, file share, or a web app—across domains. The app throws “SEC_E_KDC_UNABLE_TO_REFER (0x80090341)”. It happens after a domain migration, when you rename a server, or if someone changed DNS records without telling anyone. You know the drill: your help desk gets a ticket saying “access denied”, and Event ID 11 pops up under Kerberos in the System log.

Why It Happens

Kerberos works like a travel agent. Your client asks the local domain controller (DC) for a ticket to a service in another domain. The local DC tries to refer you to a DC in that other domain. If that referral fails—say, DNS doesn't resolve the target domain's DC, the trust is broken, or the service's SPN (Service Principal Name) is missing—you get this error. The real culprit is almost always DNS or a stale SPN. Don't bother blaming the firewall first; check DNS and trusts.

Fix It Step by Step

Step 1: Verify DNS Resolution

1. Open Command Prompt as Administrator. Press Win+R, type cmd, then right-click and pick Run as administrator.
2. Run nslookup -type=SRV _kerberos._tcp.<TargetDomain>. Replace <TargetDomain> with the full domain name (e.g., contoso.com).
3. You should see a list of DCs for the target domain. If you get “server failed” or “non-existent domain”, your DNS can't find the other domain. Check your DNS forwarders and conditional forwarders. On a domain controller, open DNS Manager, go to Conditional Forwarders, and add the target domain pointing to its DNS servers.
4. After adding, test again. You should see at least one DC address.

Step 2: Check the Trust Relationship

1. Open Active Directory Domains and Trusts on a DC in either domain.
2. Right-click the domain, choose Properties, then the Trusts tab.
3. Select the trust for the other domain and click Properties. Click Validate.
4. Enter credentials with admin access in both domains. It should return “The trust relationship was validated and is active.” If it fails, the trust is broken. You'll need to re-create it.

Step 3: Look at the SPN

1. On the server where the service runs, open Command Prompt as Admin.
2. Run setspn -L <computername> to list all SPNs for that server.
3. Find the SPN for your service. For example, SQL Server uses MSSQLSvc/server.contoso.com:1433. If it's missing or points to the wrong name, run setspn -A <SPN> <computername> to add it. If it's duplicated, use setspn -D <SPN> <wrongcomputer> to remove the duplicate.

Step 4: Clear Kerberos Tickets

1. On the client machine, open Command Prompt as Admin.
2. Run klist purge to wipe all cached tickets.
3. Then run klist tgt to verify no tickets remain. This forces a fresh authentication on the next attempt.

What to Check If It Still Fails

If you've done all the above and the error persists, check the System and Security event logs on both the client and server. Look for Event ID 11 (Kerberos) or Event ID 5719 (Netlogon). These will tell you exactly which step failed.

Also verify time sync. Kerberos requires clock skew under 5 minutes. Run w32tm /query /status on all machines. If they're off, run w32tm /resync.

Finally, if this is a SQL Server issue, check the SQL Server service account. It must have the correct SPN registered. Restart the SQL service after fixing SPNs—I've seen it cache the old SPN for hours otherwise.