skip to content

In Kerberos, how does a service that authenticated a user without Kerberos obtain a service ticket in that user's name?

level: seniorimportance: should knowfreq 42%

answer

  1. no password, no ticket from the user
  2. the service asks for a ticket to itself
  3. step one names the user, not the target
  4. the result becomes evidence for step two
  5. evidence must be forwardable to chain

basics

~20 s

Through the S4U2Self extension: the service presents its own ticket-granting ticket and asks the ticket-granting service for a service ticket to itself in the named user's name, with no proof from the user. S4U2Proxy then chains onward.

solid answer

~50 s

The extension is **S4U2Self**, usually called *protocol transition* because the user's authentication happened in some other protocol entirely — a password form, a client certificate, a one-time code — and this converts that result into a Kerberos credential. The service presents its **own** ticket-granting ticket to the ticket-granting service and asks for a service ticket **to itself**, naming the user as the client; no ticket, key or evidence from the user is involved. What comes back has the user's `cname` and `crealm` and can be used to authenticate the user locally. To reach a *third* service, the middle tier then runs **S4U2Proxy**, presenting that ticket as an evidence ticket — which the ticket-granting service accepts only if the evidence ticket is forwardable and the target service principal is one the requester is permitted to reach.

code

pseudocode · 19 lines
pseudocode
step 1 -- S4U2Self (protocol transition)
  middle tier -> ticket-granting service
      presents: its own ticket-granting ticket
      target service principal: ITSELF
      named client: the planner
  ticket-granting service -> middle tier
      service ticket to the middle tier
      cname / crealm = the planner
      usable as evidence only if forwardable

step 2 -- S4U2Proxy
  middle tier -> ticket-granting service
      presents: its own ticket-granting ticket
      target service principal: the historian
      evidence ticket: the ticket from step 1
  ticket-granting service -> middle tier
      service ticket to the historian
      cname / crealm = the planner
      issued only if the historian is a permitted target

go deeper

for a junior

Recall that a service can obtain a Kerberos credential naming a user who never authenticated with Kerberos, and that the user's own password or key is not involved anywhere in that.

for a middle

Explain the two steps: a request for a ticket to the requester itself naming the user, then a second request carrying that ticket as evidence towards a third service. Say which party presents a ticket-granting ticket each time.

for a senior

Show that the evidence ticket must be forwardable and the target must be permitted, and be able to say what the pair proves — the middle tier's identity — and what it does not: the user's presence at any moment.

for a principal

Argue about who should hold the protocol-transition permission at all. It lets one account mint user-named credentials with no user involved, so grant it only where a non-Kerberos authentication genuinely arrives.

## The problem this solves Ordinary delegation begins with the user's own Kerberos credential arriving at the middle tier. But plenty of front ends never see one. A reporting interface may authenticate a planner with a password form, a client certificate, or a one-time code, and then need to read a back-end historian **as that planner**, so the historian's own access rules — not the front end's — decide what comes back. There is no Kerberos credential to forward, because the user never spoke Kerberos. **S4U2Self** and **S4U2Proxy** are the two extensions that close that gap. They are specified outside RFC 4120 and are not part of the base protocol, so a conforming Kerberos V5 implementation need not offer them at all. ## S4U2Self, step by step 1. The middle tier authenticates the user by whatever means it actually uses. Kerberos plays no part. 2. It presents **its own** ticket-granting ticket in a `TGS-REQ`. 3. It asks for a service ticket whose target service principal is **itself**, and names the user as the client. 4. The ticket-granting service returns a service ticket to the middle tier, with the **user's** `cname` and `crealm` recorded in it. Notice what did not happen. The user presented nothing. No password, no ticket, no key, no signature. The ticket-granting service issued a credential naming a principal on the say-so of a *different* principal. That is the defining property of the extension and the source of every reasonable objection to it: **the resulting ticket is evidence that the middle tier asserted the user, not evidence that the user was present**. ## S4U2Proxy, the follow-on The ticket from S4U2Self is addressed to the middle tier itself, so on its own it lets the middle tier authenticate the user locally and nothing more. To reach the historian, the middle tier runs a second exchange: - It presents its own ticket-granting ticket again. - It names the **third** service as the target. - It attaches the ticket from step one as an **evidence ticket**. - The ticket-granting service returns a service ticket to the third service, again carrying the user's `cname` and `crealm`. Two conditions gate that second step, and both are worth naming precisely: - The evidence ticket must be **forwardable**. A non-forwardable result from S4U2Self authenticates the user to the requesting service and goes no further. - The **target must be permitted**. Unlike unconstrained forwarding, S4U2Proxy issues only towards service principals the requester is configured to reach — under constrained delegation that list lives with the middle tier, and under resource-based delegation the target service declares who may impersonate to it. | | S4U2Self | S4U2Proxy | Ordinary TGS exchange | |---|---|---|---| | Who presents a ticket-granting ticket | the middle tier | the middle tier | the user | | Whose name is in the resulting ticket | the user's | the user's | the user's | | Target of the resulting ticket | the requester itself | a third service | the service the user named | | What evidences the user | nothing | the S4U2Self ticket | the user's own credential | | Scope limit on the target | not applicable | a permitted target list | none beyond the KDC's policy | ## What the pair proves, and what it does not - It proves the **middle tier** is who it says it is — its own ticket-granting ticket carries that. - It proves **nothing about the user's presence**, at either step. Anyone who can drive the middle tier's credential can name any user. - It does **not** give the middle tier the user's key, ticket-granting ticket or password. Nothing about the user's own credentials is disclosed. - The back end sees an ordinary service ticket with the user's `cname` and `crealm` and, at the protocol level, cannot distinguish it from one the user obtained personally. Any distinction has to come from something carried alongside, not from the ticket's shape. ## Why this is narrower than forwarding, and why it is also broader It is **narrower** in reach: S4U2Proxy issues only towards permitted targets, where a forwarded ticket-granting ticket reaches whatever the ticket-granting service will serve. It is **broader** in initiative. Unconstrained forwarding needs the user to turn up with a forwardable ticket-granting ticket and a client that asks to delegate; the user is, however weakly, a participant. Protocol transition needs nobody but the middle tier — it can mint a user-named credential at three in the morning with no user anywhere. That is exactly why the permission to perform protocol transition is usually granted separately from the permission to delegate to a target, and why a middle tier that only ever sees Kerberos users should not hold it at all.

  • What must be true of the ticket S4U2Self returns before it can be used as evidence?
    It must be forwardable. The ticket-granting service accepts an evidence ticket in a follow-on S4U2Proxy request only if that ticket's `TicketFlags` permit further delegation. A non-forwardable result still authenticates the user to the requesting service, but the chain stops there.
  • Why is protocol transition a fair name for what S4U2Self does?
    Because the user's authentication happened in some other protocol entirely — a password form, a client certificate, a one-time code — and the extension converts that out-of-band result into a Kerberos service ticket. Nothing inside the Kerberos exchange itself evidences the user's presence.
  • Can S4U2Proxy be used without protocol transition at all?
    Yes. If the user authenticated to the middle tier with Kerberos, the service ticket the user already presented can serve as the evidence ticket, provided it is forwardable. The two extensions are separate permissions, and a middle tier that only serves Kerberos clients needs the second without the first.

saying these in an interview costs you the question

  • Says the user must first authenticate with Kerberos for this to work.
  • Thinks S4U2Self returns a ticket-granting ticket for the named user.
  • Believes a ticket obtained by S4U2Self proves the user was present.
  • Claims the follow-on ticket may target any service the requester chooses.
  • Assumes these extensions are defined in RFC 4120 with the base exchanges.
  • Thinks the middle tier learns the user's key or ticket-granting ticket.