STATUS_NO_TGT_REPLY (0XC00002EF): Kerberos TGT failure on domain join
This error means the Kerberos Ticket-Granting Ticket request got no reply. Usually a DNS issue or clock skew. Fix the time sync and DNS records first.
Quick Answer
Sync the client's clock to the domain controller within 5 minutes, verify DNS SRV records for the domain exist, and confirm the KDC is reachable via port 88 UDP.
What's Actually Happening Here
When a Windows machine tries to join a domain, it sends a Kerberos AS-REQ to the KDC (usually a domain controller) requesting a Ticket-Granting Ticket (TGT). The error 0XC00002EF (STATUS_NO_TGT_REPLY) means the client got zero response — no ticket, no Kerberos error, just silence. The KDC never replied.
This isn't a credential problem. It's a communication problem. The three most common causes are:
- The client can't resolve the domain's
_kerberos._tcp.dc._msdcs.<domain>SRV record in DNS. - The client's clock is off by more than 5 minutes from the domain controller (Kerberos enforces this).
- A firewall or network ACL blocks UDP port 88 between client and KDC.
I've seen this on Windows Server 2019 and 2022 when someone copies a VM snapshot and the clock drifts. Also happens when DNS scavenging accidentally deletes the SRV records.
Fix Steps
- Check time sync first. Run
w32tm /query /statuson the client. The source should be the domain controller. If the time difference exceeds 5 minutes, fix it:w32tm /resync /nowait. If that fails, manually set the time:net stop w32time && w32tm /unregister && w32tm /register && net start w32timethen resync. - Verify DNS SRV records. On the client, run
nslookup -type=SRV _kerberos._tcp.dc._msdcs.<yourdomain>. You should see at least one KDC hostname and IP. If empty, your DNS server is missing the records. On the domain controller, runnetdom query fsmoto confirm which DC holds the schema master, then restart the NetLogon service on that DC:net stop netlogon && net start netlogon. This re-registers all SRV records. - Test KDC reachability. From the client,
Test-NetConnection <KDC-IP> -Port 88. If it fails, check Windows Firewall on the domain controller — you need inbound rule for Kerberos (port 88 UDP). If you use a third-party firewall, poke a hole for UDP 88 between client subnet and KDC. - Force a Kerberos ticket request. Run
klist purge -li 0x3e7to clear cached tickets, thenklist get krbtgt. If this hangs or returns no reply, you've reproduced the error. Move to the fixes below.
Alternative Fixes If the Main One Fails
DNS Registration on Client
Sometimes the client's own DNS record is stale or missing. Run ipconfig /registerdns and wait 10 minutes, then retry the domain join. I've had cases where a client had a static IP but the reverse lookup zone had older entries — flushing both forward and reverse helped.
Check for Duplicate SPNs
A duplicate service principal name for the computer account can cause the KDC to get confused and not reply. On a domain controller, run setspn -X. It'll list any duplicates. If you find one for the target computer, remove it with setspn -D <SPN> <computername> and re-add it.
Network Path MTU Issues
Large Kerberos packets can be fragmented. If there's a router dropping fragmented UDP packets, the reply never arrives. Test with ping <KDC-IP> -f -l 1472. If it fails, lower the MTU on the client's NIC or check the network path. I've seen this on VPN connections with MTU mismatch.
Firewall Logs on KDC
Enable Windows Firewall logging on the domain controller: netsh advfirewall set allprofiles logging filename C:\Windows\System32\LogFiles\Firewall\pfirewall.log. Then attempt the domain join and look for dropped UDP 88 packets. If you see them, add an allow rule: netsh advfirewall firewall add rule name="Kerberos" dir=in protocol=udp localport=88 action=allow.
Prevention Tip
Set all domain-joined machines to sync time from the domain hierarchy. Use Group Policy: Computer Configuration > Administrative Templates > System > Windows Time Service > Global Configuration Settings and set AnnounceFlags to 5 (domain hierarchy). Also enable DNS Scavenging protection on the _msdcs zone to avoid losing SRV records. I set the scavenging no-refresh interval to 7 days and refresh to 7 days on that zone — it keeps records alive without stale data building up.
Was this solution helpful?