skip to content

A Kerberos KDC answers with KDC_ERR_S_PRINCIPAL_UNKNOWN (7) — what does that say, and how does it differ from KDC_ERR_C_PRINCIPAL_UNKNOWN (6)?

level: seniorimportance: nice to knowfreq 28%

answer

  1. two names in every request
  2. C is the client half, S is the server half
  3. not a password and not a permission
  4. exact match, so spelling and case decide
  5. a referral can replace the refusal

basics

~20 s

Error 7 says no principal matching the requested sname and realm exists in that KDC's database; error 6 says the same about the client name in cname and crealm. They point at opposite halves of the request: a service registration problem versus a sign-in one.

solid answer

~50 s

Both arrive as a `KRB-ERROR` reply and both mean "this name is not in my database" — the difference is which name. `KDC_ERR_C_PRINCIPAL_UNKNOWN (6)` concerns the client, `cname` with `crealm`, and usually surfaces at sign-in: the account does not exist, or the client is configured with the wrong realm. `KDC_ERR_S_PRINCIPAL_UNKNOWN (7)` concerns the server, `sname` with the request's `realm`, and typically means the service principal a client constructed — commonly `service/host` — is not registered under exactly that spelling, or lives in another realm. Neither is an authorization result and neither means a bad password. Where a KDC can tell the name belongs elsewhere and the client set the **`canonicalize` KDC option (bit 15)**, it may answer `KDC_ERR_WRONG_REALM` naming the right realm instead, or hand back a referral ticket-granting ticket, turning a failure into a redirection.

code

asn1 · 21 lines
asn1
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
        pvno            [0] INTEGER (5),
        msg-type        [1] INTEGER (30),
        ctime           [2] KerberosTime OPTIONAL,
        cusec           [3] Microseconds OPTIONAL,
        stime           [4] KerberosTime,
        susec           [5] Microseconds,
        error-code      [6] Int32,
        crealm          [7] Realm OPTIONAL,
        cname           [8] PrincipalName OPTIONAL,
        realm           [9] Realm,
        sname           [10] PrincipalName,
        e-text          [11] KerberosString OPTIONAL,
        e-data          [12] OCTET STRING OPTIONAL
}

-- error-code 6 : KDC_ERR_C_PRINCIPAL_UNKNOWN
--   cname / crealm name nobody in this database
-- error-code 7 : KDC_ERR_S_PRINCIPAL_UNKNOWN
--   sname / realm name nobody in this database
-- the reply is sent in the clear and is not integrity-protected

go deeper

for a junior

It is enough to know the two errors say a name was not found, and that one refers to the user's name and the other to the service's name.

for a middle

Explain which fields each error is about — cname with crealm versus sname with realm — and why an exact, case-sensitive match makes these naming faults rather than credential faults.

for a senior

Use the pair to partition a fault fast, separate it from ticket expiry and from a service that cannot open a ticket under its own key, and know when a referral replaces the refusal.

for a principal

The broader point is that naming conventions across an estate decide how many of these an integration will produce, and that error text from an unauthenticated reply should never drive an automated decision.

## Two errors, two halves of the request Every ticket request names two principals: the client, as `cname` with `crealm`, and the server, as `sname` with the request body's `realm`. The KDC looks up both in its database, and there is a distinct error for each one missing. - **`KDC_ERR_C_PRINCIPAL_UNKNOWN (6)`** — the client name is not in this database. Most often seen on an `AS-REQ`: the account genuinely does not exist, the name was typed or derived wrongly, or the client is configured with a realm that is not the user's. - **`KDC_ERR_S_PRINCIPAL_UNKNOWN (7)`** — the server name is not in this database. Most often seen on a `TGS-REQ`, once sign-in has already succeeded, which is what makes it confusing in the field: authentication clearly works, and exactly one service will not. Both arrive as a `KRB-ERROR` message, which carries `error-code` together with the `realm` and `sname` of the request and, optionally, `crealm`, `cname` and an `e-text` string. ## What error 7 usually is, in practice The archive fails for one client and works for everyone else. The name the client constructed and the name the realm registered are not the same string, and the database match is exact: | what happened | why the KDC cannot resolve it | |---|---| | the client resolved an alias and built `archive/alias.met.example` | the principal is registered under the real host name | | the host component came back in different case | component matching is byte-for-byte | | the client asked in `MET.EXAMPLE`, the service lives in another realm | the KDC holds no key for a principal it does not name | | the service was never registered as a principal at all | there is nothing to seal a ticket under | Each of those is a naming defect, not a credential defect, which is why retrying with a different password or a fresh sign-in changes nothing. ## What error 7 is not 1. **Not an authorization decision.** Kerberos does not ask whether this client should reach that service; the ticket-granting service will issue a ticket for any registered service principal to any principal holding a valid ticket-granting ticket. Whether the caller may then *do* anything is the service's decision, after the fact. 2. **Not an expiry.** An expired ticket-granting ticket is refused with `KRB_AP_ERR_TKT_EXPIRED`, and a ticket the service cannot open under its own key surfaces as `KRB_AP_ERR_MODIFIED` at the application service — a different failure, at a different step, that is frequently mistaken for this one. 3. **Not trustworthy on its face.** A `KRB-ERROR` reply is sent in the clear and is not integrity-protected the way a ticket is. Treat its contents as a diagnostic hint, not as an authenticated statement about the realm. ## When the answer is a redirection instead of a failure A name that is unknown *here* may be perfectly good *elsewhere*, and a KDC that can work out where has something better to say than "no". A client that sets the **`canonicalize` KDC option (bit 15)** declares it is willing to be handed back a name or a realm other than the one it asked with. Given that: - On a sign-in exchange, a KDC that can determine the client belongs to another realm may answer **`KDC_ERR_WRONG_REALM`** carrying that realm, and the client reissues its request there. - On a ticket-granting exchange, a KDC asked for a service it knows lives in another realm may return a **referral ticket-granting ticket** for that realm instead of an error, so the client can simply continue with the second hop. Both turn a dead end into a pointer, and both depend on the client having said it can cope. A client that does not set the option gets the plain error and stops. ## How to use the pair diagnostically The two errors are worth telling apart precisely because they partition the fault: - Error 6 puts the fault on the **client side of the name**: the account, the realm the client thinks it is in, or the KDC it is asking. - Error 7 puts it on the **server side of the name**: what the service is registered as, in which realm, and what string the client builds when it wants to reach it. That distinction is usually faster than any packet capture, because it tells you which of the two registrations to go and read — and because the half of the name that is wrong is nearly always the half nobody checked.

  • The service principal does exist, and the client still gets error 7. What usually explains it?
    The two strings differ. Component matching is byte-for-byte, so an alias-derived host component, a case difference, a missing component or a request aimed at the wrong realm all name a principal that is not the registered one. Compare the exact `sname` and `realm` the client sent against the registration, not the host it connected to.
  • Can the contents of a KRB-ERROR reply be trusted?
    Not as an authenticated statement. It is sent in the clear and lacks the protection a sealed ticket has, so anything in it — including a realm named in a wrong-realm answer — is a hint to act on, not a fact to rely on. Its value is diagnostic; the security decisions are made on tickets.

saying these in an interview costs you the question

  • Reads error 7 as a rejected or mistyped password.
  • Treats KDC_ERR_C_PRINCIPAL_UNKNOWN (6) and (7) as interchangeable.
  • Says an unknown service principal means the caller lacks permission.
  • Believes a KRB-ERROR reply is integrity-protected and can be trusted outright.
  • Assumes a KDC always names the correct realm when a principal belongs elsewhere.