Skip to content

03 · Kerberos and identity evidence

Depth: developed lesson · Prerequisites: Windows and AD · Time: two 90-minute sessions.

A ticket is evidence used in an authentication exchange. It is not a universal permission slip. To interpret an identity failure, trace who requested authentication, which service was named, what material was available at that time, and what the application decided afterward.

Outcomes

  • Draw the initial, ticket-granting and service exchanges without treating them as one event.
  • Distinguish a TGT, a service ticket, a session key and application authorization.
  • Interpret synthetic ticket metadata and identify missing evidence.
  • Inspect only your own ticket-cache metadata in an optional Windows exercise.

Follow one request through the system

In the basic Kerberos flow, the client obtains a ticket-granting ticket through the authentication service, uses the ticket-granting service to request a ticket for a particular service, and presents service authentication material to that service. The service exchange includes an authenticator; copying the visible idea of a “ticket” into a diagram does not describe every required protocol element. Session keys and tickets serve different roles. Kerberos V5 specification, RFC 4120.

Client                      KDC                     Service
  |-- initial exchange ------>|                        |
  |<-- TGT + related data -----|                        |
  |-- request service ticket ->|                        |
  |<-- service ticket + data --|                        |
  |------------ service authentication --------------->|
  |                           |              authorization decision

The arrows returning from the KDC end at the client; the right-hand service is not involved in issuing these tickets. This is a simplified sequence, not a packet capture, and omits pre-authentication details, referrals and optional mutual-authentication messages.

A service principal name identifies a service instance and associates it with the account under which the service runs. A hostname, an account name and an SPN are related identifiers, not interchangeable strings. Microsoft service principal names.

Keep four claims separate

Claim Supporting observation What it does not establish
A ticket is cached Metadata from the relevant logon session That a subsequent application request used it
A ticket names a service Its server principal That a different service will accept it
Authentication succeeded Evidence of that exchange from the relevant endpoint Permission to read or change every application object
An object was read Request, identity context and returned object Write access or authority over other objects

A failed application request can follow successful authentication. Conversely, a missing cache entry alone cannot diagnose every failure: you may be inspecting the wrong context, the request may not have reached ticket acquisition, or the application may be using another authentication mechanism. Treat these as alternatives to test, not conclusions already proven.

Session 1: solve the metadata cases

The following cases are synthetic teaching records, not captured tickets. Times are UTC on the same fictional day. Assume the clocks agree and that no renewal or replacement occurs during each case. The worksheet supplies no keys or credential material.

Case Client Server principal in record Validity Observation
A Alice@LAB.TEST HTTP/web.lab.test 09:00–10:00 At 09:30 the app authenticates Alice, then denies report 202
B Alice@LAB.TEST HTTP/web.lab.test 09:00–10:00 At 10:30 the learner points to this old record as proof of current access
C Alice@LAB.TEST HTTP/web.lab.test 09:00–10:00 At 09:30 the learner claims this proves access to a file service
D Alice@LAB.TEST No record supplied Unknown A request fails before an application response is observed

For each case, write the strongest supported claim and one unjustified conclusion. Identify the next useful observation without changing policy or credentials.

Worked interpretation

A: The stated authentication succeeded, but report access was denied. Inspect the intended report policy and request context; do not call every denial a Kerberos failure.

B: The supplied validity interval has ended. This record alone does not prove current access. A later replacement ticket or a different mechanism would need separate evidence.

C: The record names an HTTP service. It is not evidence that a file-service request was authenticated or authorized.

D: The failure location is unresolved. Check the exact error, target naming, reachability and relevant client context before selecting a protocol diagnosis.

Now add case E: “The application returned a report, but no authentication evidence was retained.” Can the report result prove Kerberos was used? No. Separate a successful operation from the mechanism you believe enabled it.

Session 2: inspect your own Windows cache

On an authorized Windows lab machine, open an ordinary terminal in your own current session and run:

klist

Without additional parameters, this lists cached tickets for the current user. Inspect only metadata such as the client, server and validity times; record a redacted example or that no entries were present. Do not dump encoded ticket material, purge caches, request tickets, target other sessions or alter bindings for this exercise. Microsoft klist reference.

If your lab uses a local account or has not used Kerberos, an empty cache can be expected. It is not a failed lesson. Record what the command actually showed and which broader questions it cannot answer. A similarly named command on another OS is not automatically the same implementation; this exercise specifies Windows.

Native execution is optional and has not been established by the macOS course build. Complete the five synthetic cases when Windows is unavailable, and mark the practical Windows observation as pending. Do not convert worksheet completion into demonstrated AD operations.

A diagnostic worksheet that preserves uncertainty

Use one row per observation:

Time and timezone:
Client and logon context (redacted):
Intended service and resource:
Observed stage: naming / connection / ticket acquisition / service authentication / authorization
Evidence reference:
Hypothesis:
Competing explanation:
Smallest next observation that distinguishes them:

The stage field can be unknown. Do not force an error into a familiar category. For example, a hostname resolution problem and an application authorization denial occur at different points; changing account permissions before locating the failure can make diagnosis worse.

Evidence and acceptance

Save the five-case interpretation, a reconstructed exchange diagram and one diagnostic worksheet. Each interpretation must distinguish a recorded fact from a proposed explanation. If you performed klist, keep the raw output private and attach only sanitized metadata to your learning note.

Safety and scope

Use your current lab session only. This lesson does not request credential extraction, replay, ticket forging or changes to identity configuration. The metadata inspection is read-only; close the terminal and preserve the redacted record afterward.

Teach-back

  1. Why does a service ticket not grant arbitrary application permissions?
  2. What separates a cache observation from proof that a request used Kerberos?
  3. Which assumption makes the time comparison in case B interpretable?
  4. Why would changing several identity settings at once weaken an investigation?

Continue: 08 · Web authorization, then 05 · Detection. The remote-administration lesson now develops prerequisite reasoning and an optional native lab; delegation, NTLM and deeper identity paths remain explicit coverage gaps.