skip to content

A Kerberos TGS-REQ returns KDC_ERR_S_PRINCIPAL_UNKNOWN for a render queue host: what does that tell you?

level: seniorimportance: should knowfreq 38%

answer

  1. a lookup, not a reachability test
  2. the KDC contacted nothing
  3. the reply echoes what you asked for
  4. typo and absence are indistinguishable
  5. no key to seal a ticket under

basics

~20 s

Only that the sname and srealm in the request did not resolve to a principal the KDC holds a long-term key for. It says nothing about the service being reachable, running, or permitted to the caller, and a typo produces it identically to a missing registration.

solid answer

~50 s

Error 7 is a **name resolution** answer from the KDC, nothing more. The ticket-granting service takes `sname` and `realm` out of the `KDC-REQ-BODY`, looks for a principal with a long-term key it can seal a ticket under, and fails. So the reply tells you the name you asked for is not one this realm can issue for — and the `KRB-ERROR` echoes that name back in its own `realm`/`sname`, which is the most useful field in the whole reply. It does **not** tell you the host is down, the service is stopped, the network is broken, or that the caller lacks permission: none of those were tested, and the KDC never contacted the service. A typo, a host name the client expanded differently, a wrong name type and a genuinely unregistered service all produce byte-identical replies.

code

asn1 · 13 lines
asn1
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
    pvno       [0]  INTEGER (5),
    msg-type   [1]  INTEGER (30),
    stime      [4]  KerberosTime,
    susec      [5]  Microseconds,
    error-code [6]  Int32,           -- 7 = KDC_ERR_S_PRINCIPAL_UNKNOWN
    crealm     [7]  Realm OPTIONAL,
    cname      [8]  PrincipalName OPTIONAL,
    realm      [9]  Realm,           -- service realm asked for
    sname      [10] PrincipalName,   -- the name that did not resolve
    e-text     [11] KerberosString OPTIONAL,
    e-data     [12] OCTET STRING OPTIONAL
}

go deeper

for a junior

Recall that this error is about a name, not a machine. The KDC could not find the service principal it was asked for, and it never tried to contact anything.

for a middle

Explain the lookup: sname plus realm must resolve to a principal whose long-term key can seal the ticket, and the KRB-ERROR echoes the name that failed.

for a senior

Show the diagnostic discipline — read the echoed name before touching the service, know that reaching this error means the ticket-granting ticket was accepted, and note the error is not integrity-protected.

for a principal

Consider the design consequence: a name-resolution failure that cannot distinguish absence from a typo is the price of not offering an enumeration oracle, and any tooling you build must supply the context the protocol deliberately withholds.

## What the KDC actually did before answering A `TGS-REQ` names its target in the `KDC-REQ-BODY` as `sname` (a `PrincipalName`) plus `realm`. To issue a ticket the ticket-granting service must find a principal of that name **and hold a long-term key for it**, because that key is what seals the ticket. If the lookup fails, it answers a `KRB-ERROR` with `error-code` 7, `KDC_ERR_S_PRINCIPAL_UNKNOWN`. That is the entire test. Reading more into it than a failed lookup is the mistake this question is built around. ## What error 7 answers, and what it leaves open | question an engineer wants answered | does error 7 answer it? | |---|---| | Is this name one the realm can issue a ticket for? | **yes** — no | | Is the render queue process running? | no — never tested | | Is the host reachable from the client? | no — the KDC contacted nothing | | May this caller use that service? | no — the ticket-granting service does not decide use | | Did the client spell the name correctly? | **indistinguishable** from the service being unregistered | | Is the client's own ticket-granting ticket good? | it was accepted, or you would have a different error | That last row is worth stating aloud in an interview: reaching error 7 at all means the presented ticket-granting ticket and its `Authenticator` were accepted. The request got past authentication and failed at the ask. ## Why a typo and a missing service look identical The KDC has no notion of "nearly this name". Every one of these produces the same code: - a mistyped service name; - a host name the client resolved to a short form where the realm registered a long one, or the reverse; - the right name under the wrong `name-type`, where the realm's lookup is sensitive to it; - a service that genuinely was never given a principal and a key. The protocol cannot distinguish them because they are the same event from the KDC's side: a lookup returned nothing. This is a deliberate property, not an omission — an error that distinguished "close but wrong" from "absent" would be a name oracle. ## How to read the reply properly The `KRB-ERROR` carries the service `realm` and `sname` it failed to resolve, so the first diagnostic move is to compare **the exact name the client asked for** against the names the realm knows — not to check whether the render queue is up. Most of the time the reply already contains the bug, in a form the application's log line ("authentication failed") has thrown away. Two cautions that separate a senior answer: - **A `KRB-ERROR` is not integrity-protected.** It arrives without a key over it, so it is a diagnostic, not evidence. In a hostile-path scenario it can be forged; in an ordinary one it is simply the KDC's opinion of a name. - **`KDC_ERR_C_PRINCIPAL_UNKNOWN` (6) is a different failure** and you rarely see it here: in a TGS exchange the client is identified by the ticket-granting ticket it presented rather than by a name looked up afresh, so it is the *service* name that fails to resolve. ## The wrong first move, and the right one The wrong first move is to go and look at the render queue. Nothing in this failure involved it; not one packet reached it. The right sequence is: 1. Read `sname` and `realm` out of the `KRB-ERROR` — that is the string the client actually sent. 2. Compare it, character for character, with a name the realm can issue for. 3. Only if the name is right, look at how the client composed it — the name-type it used, and how it derived the host component. ## The line that separates this from an authorization failure A ticket-granting service does not ask whether the requester should be using the service. Its job is to find a principal, seal a ticket under that principal's key, and hand it over. Any decision about whether this artist may write to the render queue is made later, by the service itself, from the `cname` and `authorization-data` inside the ticket. So error 7 is never an access-denied message, and answering it as though it were sends the investigation into the permissions of a service that was never consulted.

  • Why does error 7 not distinguish a typo from an unregistered service?
    Because from the KDC's side they are the same event: a lookup that returned nothing. Distinguishing them would require reporting near-misses, which turns the error into an oracle for enumerating the names a realm holds. The cost is a diagnostic that cannot separate the two, which is why the echoed `sname` matters.
  • Why do you rarely see KDC_ERR_C_PRINCIPAL_UNKNOWN (6) from a TGS exchange?
    In a TGS exchange the client is identified by the ticket-granting ticket it presents, not by a name the KDC looks up afresh. The client identity has already been established by the `PA-TGS-REQ`, so the name that can fail to resolve is the service name in `sname`.
  • Can you treat the KRB-ERROR as reliable evidence in an incident?
    Not on its own. A `KRB-ERROR` is delivered without integrity protection, so it is a diagnostic rather than evidence: it can be forged by anything on the path, and it reflects only what one KDC thought of one name at one moment. Corroborate it against the realm's own view of the name.

saying these in an interview costs you the question

  • Reads error 7 as the service being down or unreachable
  • Treats it as access denied for the calling principal
  • Thinks the KDC contacted the service to check it
  • Says the error proves the client's TGT was rejected
  • Expects the error to distinguish a typo from a missing registration