Troubleshoot Kerberos and Service Principal Names
When a domain user can sign in but a Windows service rejects integrated authentication, Kerberos may have failed or the client may have used another authentication method. A Service Principal Name (SPN) maps a service instance to the AD account that runs it. A missing, duplicate, or incorrectly owned SPN can prevent the Key Distribution Center (KDC) from issuing the expected service ticket.
Start with the affected client, target service name, timestamp, and service identity. The checks below are diagnostic.
Check the Client's Domain and Time Path
BaselineKerberos relies on a reachable KDC and synchronized clocks. Check which DC the client discovers and review time status. If the affected service is on a server, run the same checks there and compare the results.
nltest /dsgetdc:corp.example.comw32tm /query /status❯ Illustrative Output (Results Vary)
DC: \\DC01.corp.example.comAddress: \\10.20.0.10The command completed successfullyInspect Tickets for the Target Service
Ticket CheckRun this in the affected user’s logon session. List cached tickets, then request a ticket for the exact service name the application uses. A successful request proves the client obtained a ticket for that SPN; it does not by itself prove the service can decrypt it or authorize the user.
klistklist get HTTP/app01.corp.example.com❯ Illustrative Output (Results Vary)
Cached Tickets: (1)#0> Client: analyst @ CORP.EXAMPLE.COM Server: HTTP/app01.corp.example.com @ CORP.EXAMPLE.COMQuery SPN Registration Before Editing
OwnershipUse the AD command-line tool to query the exact SPN and search for duplicates. Check the full service name, aliases, port usage where applicable, and the account configured on the service. Do not assume the computer account owns an SPN when the workload runs under a service account or gMSA.
setspn -Q HTTP/app01.corp.example.comsetspn -Xsetspn -L CORP\gmsaApp01$❯ Illustrative Output (Results Vary)
Checking domain DC=corp,DC=example,DC=comCN=gmsaApp01,OU=Service Accounts,DC=corp,DC=example,DC=com HTTP/app01.corp.example.comExisting SPN found!Match the SPN to the Service Configuration
Verify OwnershipCompare the SPN with the URL or alias used by the client and the identity configured for the service. Confirm DNS resolves the client-facing name to the intended server, check for a load balancer or alias, and review service authentication logs. If the service account changed, check whether the SPN remained on the old identity or was registered twice. For a confirmed missing SPN, use setspn -S only after the owner approves the exact mapping; avoid -A and do not delete an SPN until every dependent workload is known.
Client-facing name: HTTP/app01.corp.example.comDNS target: APP01.corp.example.comConfigured service identity: CORP\gmsaApp01$SPN owner from setspn -Q: CORP\gmsaApp01$❯ Illustrative Output (Results Vary)
Name resolves to intended service: YesSPN owner matches service identity: YesApproved directory change required: NoRequest a Fresh Ticket and Verify the Workload
RetestAfter an approved directory correction has replicated, retest from the same client and service path. If stale tickets are suspected, coordinate a ticket-cache refresh for the affected user session; clearing tickets can temporarily affect other Kerberos applications in that session. Request the target ticket again and verify the application’s authentication logs. Capture the client, URL, service identity, timestamps, SPN query output, and DC used.
# Run in the affected user's session after the change has replicated.klist get HTTP/app01.corp.example.comklist❯ Illustrative Output (Results Vary)
Service ticket for HTTP/app01.corp.example.com: PresentApplication authentication check: Passed