Articles
Kerberos Interview Questions: Ticket Flow, SPNs, and Authentication Failures
Prepare for Kerberos interview questions on ticket flow, SPNs, service accounts, cache context, clock skew, and evidence that explains authentication failures.
Kerberos interview questions become easier when you separate three events: obtaining a ticket, presenting it to the intended service, and receiving permission to perform an operation. A browser reaching the right server does not prove that it requested the right service identity. A service ticket in a cache does not prove that the server accepted it.
Find the last successful exchange, then check the identity and key at the next boundary. This guide uses a ticket timeline and an original service-account mismatch exercise.
Official protocol and implementation facts are labeled where introduced. The examples are original preparation exercises, not captured incidents or candidate reports of an employer's interview.
Explain the ticket flow without confusing the recipients
Official Windows overview: Microsoft describes a client, a service and a trusted Key Distribution Center, or KDC. In Windows domains, the KDC runs on domain controllers and uses Active Directory's account database. Kerberos itself is not a synonym for Active Directory; distinguish the protocol from this implementation.
Our original single-realm timeline follows an employee connecting to a reporting service. It omits cross-realm referrals and implementation-specific preauthentication details so that each boundary remains clear.
| Exchange | Client's purpose | Result or recipient |
|---|---|---|
| AS request/reply | Establish initial credentials | Client receives a TGT and associated session-key information |
| TGS request/reply | Request credentials for a named service | Client receives that service's ticket and session-key information |
| AP request, with AP reply when required | Authenticate to the application | Target service receives its ticket and an authenticator |
Protocol basis: RFC 4120 defines these exchanges. AS means Authentication Service; TGS means Ticket-Granting Service. They are logical KDC functions, not necessarily separate machines. The application exchange is with the target service. Mutual authentication uses the appropriate reply; do not assume every application establishes it merely because a ticket exists.
Ask a follow-up: “If the reporting server is unavailable, which exchanges could still succeed?” In this timeline, initial authentication and service-ticket issuance can succeed before the client connects to that server. That observation helps locate a failure; it does not prove the report can be read.
Which key protects the ticket?
Official MIT implementation explanation: the encryption-types documentation separates the service's long-term key, the newly chosen session key, and the key protecting the reply to the client. Those are different roles.
In the ordinary exchange, the TGT's encrypted contents are protected for the ticket-granting service. The application ticket's encrypted contents are protected for the target service. The client receives its usable session-key information separately in the protected reply. It does not decrypt the TGT itself with the user's password.
For an ordinary password-based AS exchange, the client's long-term key is relevant to reply protection. Other initial-authentication mechanisms need their own explanation. Avoid turning this simplified description into a claim that all Windows sign-ins transmit or use passwords in the same way.
The TGS reply is protected using the authenticating ticket's session key or an applicable subkey. In an application request, the authenticator uses the service-ticket session key. Naming all these values “the encrypted password” loses the trust relationships that an interviewer is asking you to explain.
Original rehearsal test: point to each recipient in the timeline and explain which protected object it can interpret. If your explanation requires the reporting server to decrypt the TGT, redraw the flow before discussing troubleshooting.
Why is a ticket alone insufficient?
Protocol fact: RFC 4120's application exchange combines a ticket with an authenticator that demonstrates knowledge of the session key. Tickets can be reused within their validity; an authenticator must not simply be reused for another authentication attempt.
Official replay protection: MIT's replay-cache explanation describes tracking recently presented authenticators to detect duplicates. This is different from the client credential cache that stores reusable credentials.
Our inference for incident reasoning is that “the ticket is not expired” leaves important questions unanswered. Was the requested service correct? Was a fresh authentication exchange performed? Did the server accept the authenticator? A screenshot of a cache entry cannot answer all three.
Authentication also does not automatically protect every byte of subsequent application traffic. Explain the application's negotiated protection or transport separately. In an interview, ask what the service actually requires instead of treating a successful Kerberos exchange as proof of a secure end-to-end application.
SPNs identify services, not just reachable hosts
Official Windows behavior: Microsoft's SPN troubleshooting article explains that a service principal name identifies the service and is associated with the relevant AD account. Custom service accounts require appropriate registrations; some computer-account service classes have HOST mappings. Therefore, “there is no explicit HTTP entry” is not a universal diagnosis for every Windows service.
Our exercise chooses an explicit custom-account mapping. The application requests HTTP/reports.example.invalid. DNS directs the connection to the intended host, and TLS validation succeeds. Yet the SPN is registered to an old service account while the running service uses a new account.
| Original exercise evidence | Observed value |
|---|---|
| Requested service identity | HTTP/reports.example.invalid |
| Directory owner of that SPN | EXAMPLE\svc_reports_old |
| Configured ticket-accepting identity | EXAMPLE\svc_reports_new |
| Last successful boundary | Service ticket issued by the KDC |
| Failing boundary | Target service cannot decrypt the presented ticket |
Official failure mechanism: Microsoft documents the wrong-account case: the KDC protects the ticket using the credential associated with the registered SPN owner, while the target expects a different credential. KRB_AP_ERR_MODIFIED can result. It is not proof that someone edited the packet maliciously, and it is not by itself proof of this one root cause.
In our fixture, DNS reachability is true and SPN ownership is wrong at the same time. Resetting the employee's password would not fix that mismatch. Preserve the requested SPN, directory ownership evidence and service configuration before recommending an approved correction.
Separate missing, duplicate and wrong-owner SPNs
Official error distinction: the SPN troubleshooting article connects KDC_ERR_S_PRINCIPAL_UNKNOWN and KDC_ERR_PRINCIPAL_NOT_UNIQUE to service-identification problems. These belong to the KDC request boundary. A ticket already issued and rejected by its recipient presents a different starting point.
Our diagnostic matrix changes one fixture variable at a time. It predicts where to investigate; it is not an exhaustive Kerberos error-code simulator.
| Fixture variation | Evidence to request next |
|---|---|
| No matching registration | Actual requested SPN and relevant directory search scope |
| Two owners for the same explicit SPN | Duplicate-search results and account ownership |
| One owner, different accepting account | Service configuration and registered credential owner |
| Same owner, unavailable ticket key version | Ticket version and deployed credential-version metadata |
| Authentication succeeds, report access denied | Application authorization decision and resource permissions |
An alias adds another variable. A URL, DNS result and service principal are not automatically interchangeable. Official MIT configuration exposes hostname canonicalization and realm mappings in krb5.conf. Windows and individual applications have their own behavior. Capture the principal actually requested rather than inventing it from a CNAME or assuming every client follows the same rule.
When only one alias fails, compare the working and failing names while holding the client and service identity constant. When only one service node fails, compare that node's credential deployment with its peers. These controlled comparisons reveal more than changing multiple settings at once.
Inspect the correct cache and credential context
Official cache semantics: MIT defines a credential cache as storage for credentials, principal names, lifetimes and flags. It is distinct from a keytab, which holds long-term credentials. A valid TGT permits additional ticket requests; a cached service ticket permits reuse without a new KDC request for every connection.
Windows tool scope: Microsoft's klist reference lists TGTs and service tickets for a logon session. Its default context is the signed-in user's session. Inspecting your interactive shell therefore does not establish which tickets a background service used.
Our evidence recommendation is to record the relevant client principal, requested server principal, ticket times, session context and observed error, then correlate them with the service and KDC logs. Preserve readable metadata without sharing ticket material or secret keys. State which context you inspected in the interview answer.
For directory evidence, Microsoft documents setspn: -L lists an account's registrations, -Q queries registrations, and -X searches duplicates. Scope matters, especially across domains or forests. These read operations help establish ownership; they do not grant permission to modify it.
A directory repair is a separate controlled change. Identify the intended credential owner and application configuration first. Likewise, clearing a ticket cache changes the experiment. Save the relevant observations before requesting fresh credentials; do not make “purge everything” your opening diagnosis.
Clock skew, key versions and encryption types need separate checks
Official MIT setting: krb5.conf documents a default clock-skew allowance of 300 seconds. Actual policy and implementation matter. Ticket validity and authenticator freshness are related checks, but an eight-hour ticket does not make an eight-hour clock difference acceptable.
Our recommendation is to compare actual clock offsets and time sources, not just time-zone labels. Two correctly synchronized machines can display different local times. A skew error supports checking synchronization; it does not justify weakening the freshness policy.
Official credential metadata: MIT's keytab documentation identifies principal, key version number, encryption type and key as distinct entry fields. Our second fixture assumes a ticket protected with version 8 while the service has only version 7. Account names match, yet the service lacks the required credential version. Version numbers are metadata, not proof that two keys contain identical bytes.
The local conceptual check confirms that an ownership mismatch and a version mismatch fail different predicates. It does not perform cryptography, authenticate a real principal or predict the exact error emitted by every implementation.
If an encryption-type error appears, inspect the supported keys and policies of the participating components. Do not treat enabling older algorithms as an automatic fix. Keep account ownership, credential version and algorithm compatibility as separate hypotheses so that correcting one does not hide another.
Authentication, authorization and the second hop
Official implementation boundary: Microsoft's SSO guidance explains that client and service configuration affect whether Kerberos is used. A working login through another mechanism does not establish that the intended Kerberos exchange succeeded.
Our preparation answer distinguishes three claims: the service accepted the identity; application policy allowed the requested report; a front-end service could authenticate to a separate back end in the required context. Success at the first does not establish the other two.
For a second-hop failure, draw the client-to-front-end and front-end-to-back-end paths separately. Ask whose identity the back end is expected to see. Delegation is a deliberate configuration and trust decision, not permission inferred from a user's ability to sign into the front end.
Finish a troubleshooting answer with a falsifiable check: reproduce the same service name and context, observe the expected authentication exchange, and verify one allowed and one forbidden operation. A corrected SPN with no observed service acceptance is incomplete evidence; a successful report with an unexpected authentication mechanism answers a different question.
Sources and Further Reading
- Microsoft: Windows Kerberos authentication overview
- IETF RFC 4120: Kerberos V5 protocol
- MIT: Ticket, reply and session-key encryption roles
- Microsoft: SPN registered to the wrong account
- Microsoft: Unknown or nonunique service principals
- Microsoft: setspn command reference
- Microsoft: Windows klist command reference
- MIT: Credential cache
- MIT: Keytab entries and credential metadata
- MIT: Replay cache
- MIT: krb5.conf, canonicalization and clock skew
- Microsoft: Kerberos single sign-on troubleshooting
Research checked October 4, 2026. Windows-specific guidance and MIT krb5 1.22.2 documentation are identified separately. The timelines and account/version fixtures are original; no live domain or candidate interview report was used.