Kerberos tickets, service names, and key ownership

Mechanism

Kerberos separates initial authentication from service authentication. A ticket is issued for a principal and encrypted for the service expected to consume it. Service principal names, account keys, ticket flags, time synchronization, and delegation policy determine behavior. Ticket possession does not grant every permission enforced by the application.

Practical method

Identify client, domain, service principal, and target service. Inspect cached tickets and lifetimes. Map the service principal to its account and key ownership. Separate authentication success from application authorization and inspect clock or name errors before assuming a cryptographic issue.

klist
setspn -Q HTTP/lab.example

Interpreting evidence

An accepted service ticket establishes authentication to that service context. The application may still reject the requested object or operation.

Pitfalls and limits

Name canonicalization and duplicate SPNs can cause confusing failures. Kerberos and NTLM fallback produce different evidence. Delegation requires specific policy and ticket conditions.