0x80090311 SEC_E_NO_AUTHENTICATING_AUTHORITY Fix

DNS Misconfiguration (the real culprit 80% of the time)

Every time I see this error — 0x80090311 — the client can't resolve a domain controller's Kerberos SRV record. Period. The error means "I looked for a DC, found nothing, gave up."

On the affected machine, open an admin command prompt and run:

nslookup -type=SRV _kerberos._tcp.yourdomain.local

If that returns nothing or a bogus IP, your DNS is broken. The fix depends on what broke it:

1. Client pointing at wrong DNS server — Check NIC properties. Should point at a domain controller (or DC-conditional forwarder). Not 8.8.8.8. Not your ISP's DNS. Run ipconfig /all and verify.
2. Missing SRV records — On a healthy DC, open DNS Manager, expand Forward Lookup Zones → your domain → _tcp. You should see _kerberos and _kpasswd entries. If they're missing, the DC didn't register them. Run ipconfig /registerdns on each DC, then restart the Netlogon service (net stop netlogon && net start netlogon). Wait 10 minutes, re-check.
3. Stale DNS records — Old DC entries pointing at decommissioned servers. Scavenge stale records or manually delete them.

After fixing DNS, flush the client cache: ipconfig /flushdns && klist purge. Then try authentication again.

Time Skew Between Client and Domain Controller

Kerberos won't tolerate a clock difference >5 minutes (default). The error isn't always "time skew" — sometimes it manifests as this 0x80090311 because the client can't even complete the initial exchange.

Check both machines' time:

• On the client: w32tm /query /status — look at "Source" and "Last Successful Sync Time".
• On the DC: same command. Should show a reliable NTP source or the PDC emulator.

If time is off, force sync:

w32tm /resync /nowait
w32tm /config /update

Then verify with w32tm /query /status. If the client won't sync, check the Windows Time service is running (net start w32time).

Pro tip: If the client is in a different forest or workgroup and trying cross-forest auth, time mismatch between the two forests kills it. Sync both to the same NTP source — use pool.ntp.org if you have to.

Firewall or Network Path Blocking Kerberos

Kerberos uses UDP/TCP port 88. If a firewall (Windows Defender, hardware, cloud NSG) blocks it, the client can't reach the DC. This one's easy to miss because basic ping and RDP might work.

On the client, test connectivity to a DC's Kerberos port:

Test-NetConnection dc01.yourdomain.local -Port 88

Or from cmd:

telnet dc01.yourdomain.local 88

If it fails, check:

• Windows Firewall — On the DC, ensure inbound rule "Active Directory Domain Controller - Kerberos (TCP-In)" is enabled. Also UDP 88.
• Network firewalls — Any ACL between client and DC subnet must allow UDP/TCP 88, 389, 445, and 464 (Kerberos change password).
• VPN or DirectAccess — Split-tunnel configs often drop Kerberos traffic. Force all domain traffic through the VPN tunnel.
• IPv6 — If IPv6 is disabled on the client but the DC registers AAAA records, the client may try IPv6, fail, and never fall back to IPv4. Enable IPv6 or disable it on the DC side. I've seen this catch people on Server 2012 R2.

For cloud VMs (AWS, Azure), check the security group / NSG — outbound UDP 88 is often blocked by default.

Quick Reference Summary

Start with DNS — it's the easiest to check and the most common. If you skip straight to firewall rules, you'll waste an hour. I've seen sysadmins rebuild the entire domain over this error. Don't be that person.