Kerberos tickets: TGTs, service principals and clock failures
Trace a Kerberos sign-in from ticket-granting ticket to service access. Separate clock skew, service-principal mistakes and authorization failures using concrete evidence.
TL;DR: Kerberos gives a client a ticket-granting ticket and then tickets for named services. Diagnose which exchange failed before changing passwords: time synchronization, service-principal registration and the service's key can each break an otherwise reachable application.
A ticket names a relationship
The key distribution center, or KDC, is trusted by clients and services. In a Windows domain it runs on domain controllers and uses AD DS account information. A ticket-granting ticket, usually shortened to TGT, lets the client request service tickets without submitting the user's password for each application connection.
A service ticket is issued for a particular service principal. The client presents it to the service, which must be able to validate it with the appropriate key material. Authentication establishes identity; the service still applies its authorization rules.
The Windows Kerberos overview describes these roles. For the protocol exchanges and ticket semantics, use RFC 4120.
The diagram omits protocol fields to show trust boundaries. It does not imply that passwords travel in plaintext or that every connection creates a new TGT.
Time is part of replay protection
Tickets have validity intervals. Authenticators include time-related information that helps prevent replay. If client and service clocks differ beyond the configured tolerance, a valid account can fail authentication. Check the effective policy rather than declaring one universal tolerance for every deployment.
A responder should inspect the actual time source and offset, including the domain's time hierarchy and any virtualization configuration affecting clocks. Simply changing the displayed local time zone does not fix an incorrect underlying clock. DNS matters too: locating a KDC and choosing the intended service name are separate prerequisites, so compare DNS evidence with ticket evidence.
Worked diagnosis: the alias broke single sign-on
Imagine an internal reporting application that previously used its server hostname. A team introduces a friendly DNS alias. TCP connections and TLS succeed through the alias, but integrated authentication fails. Some clients fall back to another mechanism, so the dashboard reports an inconsistent failure rate.
Record the name requested by the client, the service principal in the ticket request, and the account under which the service runs. A DNS alias creates a name-to-address mapping. It does not by itself register the corresponding service principal on the correct identity.
Check whether the expected SPN is missing, duplicated, or attached to an account whose key the running service does not use. Change only the relevant registration through the directory administration process. Repeatedly restarting the service will not repair an incorrect identity mapping.
After correction, test with fresh authentication evidence and verify which mechanism actually succeeded. A green browser page could represent fallback authentication. Avoid purging every user's tickets as a first response; doing so can turn a partly cached service into a broader authentication incident.
| Evidence | Candidate explanation | Next discriminating check |
|---|---|---|
| Clock-skew error | Time differs beyond policy | Compare clock sources and measured offsets |
| Unknown or non-unique service principal | Missing or duplicate SPN | Inspect the requested SPN and owning account |
| Ticket validation/decryption error | Wrong key or account mapping | Compare service identity, SPN and recent rotations |
| Authentication succeeds, resource denied | Authorization policy | Inspect the resource ACL and presented identity |
Microsoft's Kerberos troubleshooting guidance maps error families to evidence. Treat an error code as a hypothesis selector, not a complete root-cause statement.
Cached tickets complicate change verification
Existing sessions can outlive the configuration change being tested. Capture ticket validity and issuance context before deciding whether a repair worked. Test both a fresh client path and an already established session when assessing the operational impact of a credential rotation.
Also separate ordinary service authentication from delegation. A front-end service accepting the user's ticket does not automatically have permission to access another service as that user. A multi-hop application adds an explicit delegation design and a larger security review.
Questions to answer from the trace
A TGT exists, but the application rejects the user. Is Kerberos ruled out? No. The service-ticket request or service-side validation may still fail. Follow the exchange beyond initial sign-in.
Will increasing clock tolerance fix the architecture? It may mask an underlying time failure while weakening the intended replay boundary. Repair time distribution, confirm offsets and then retain a justified policy.
Does a valid service ticket guarantee access to a file? No. The file service authorizes the authenticated identity against its own permissions. That distinction is also central to identity-based access.