Fix SEC_E_TARGET_UNKNOWN (0x80090303) - 3 Steps

What's Actually Going On

You're trying to connect to something — a SQL Server, a remote desktop, a file share — and you get SEC_E_TARGET_UNKNOWN (0x80090303). The error message says "The specified target is unknown or unreachable." That's Kerberos telling you it can't find the server's Service Principal Name (SPN) in Active Directory. Nine times out of ten, it's a DNS or SPN problem. I've seen this blow up entire print queues and kill remote desktop sessions for days.

Here's the fix in three stages. Start with the 30-second one. If that doesn't work, move to the 5-minute fix. If you're still stuck, you're in for the 15+ minute deep dive.

30-Second Fix: DNS Triage

Open a command prompt as Administrator and run:

ipconfig /flushdns
nslookup your-server-name.yourdomain.local

Replace your-server-name.yourdomain.local with the actual server FQDN you're trying to reach. If nslookup returns the correct IP, your DNS is fine. If it fails, you've found the problem — fix DNS first.

Had a client last month whose entire print queue died because their DHCP server handed out a stale DNS zone. Five minutes of troubleshooting, and flushing DNS fixed it for everyone.

5-Minute Fix: Check the SPN

If DNS is working, the next suspect is the SPN. Kerberos needs a registered SPN for the service you're accessing. Run this from any domain-joined machine:

setspn -Q MSSQLSvc/sqlserver01.mydomain.com:1433

Replace with the service type (e.g., MSSQLSvc for SQL Server, HOST for RDP, HTTP for IIS) and the server's FQDN. If no SPN is found, you need to register one.

For SQL Server, the most common cause, run:

setspn -A MSSQLSvc/sqlserver01.mydomain.com:1433 domain\sqlserviceaccount

Note: the service account must be running the SQL Server service. If it's LocalSystem, use the computer account: domain\sqlserver01$.

If you see duplicate SPNs (setspn -X shows duplicates), that's your problem. Duplicate SPNs break Kerberos. Remove the duplicate with setspn -D.

15+ Minute Advanced Fix: Kerberos Ticket and Domain Join

Still stuck? Let's go deeper.

1. Clear Kerberos Tickets

Run on the client machine (the one getting the error):

klist purge
klist -li 0x3e7 purge

This clears cached tickets. Then try connecting again. If it works, you had a stale ticket.

2. Check Time Sync

Kerberos is picky about time. Run:

w32tm /query /status

If the time is off by more than 5 minutes from your domain controller, Kerberos tickets won't work. Fix with:

w32tm /resync /nowait

I've seen this error pop up after daylight saving time changes on machines not joined to the domain properly.

3. Verify Domain Join

Run on both client and server:

nltest /dsgetdc:yourdomain.com

If it fails, the machine isn't properly domain-joined or can't find a domain controller. Rejoin the domain if needed.

4. Check the Event Logs

Open Event Viewer, go to Applications and Services Logs > Microsoft > Windows > Kerberos > Operational. Look for event ID 4 (Kerberos ticket request failed) or 7 (SPN mismatch). The details will tell you exactly which SPN is missing or wrong.

One time, I had a server with a typo in the SPN — MSSQLSvc instead of MSSQLSvc. Took me 20 minutes to spot it. The event log pointed me right to it.

When to Give Up and Use NTLM

If you're in a pinch and can't fix Kerberos right now, force NTLM fallback. For SQL Server, add Trusted_Connection=yes;Persist Security Info=true;Network Library=DBMSSOCN to your connection string. For RDP, check the box "Allow connections only from computers running Remote Desktop with Network Level Authentication" on the server. But this is a band-aid, not a fix.

Once you've sorted Kerberos, remove those workarounds.

Bottom Line

Start with DNS — it's the fastest and most common fix. If that's clean, check the SPN. If you're still stuck, purge tickets, sync time, and dig into the Kerberos event log. This error almost never lies — it's telling you exactly what's missing. Listen to it.