Wrong Number! Taming the Kerberos Identity Crisis

If your Kerberos client is getting a KRB_AP_ERR_NOT_US response and the KDC log shows BAD TGS SERVER NAME, the problem is almost always a mismatch between the ticket’s service principal and the realm the KDC expects. Understanding the exact check the KDC performs makes the fix much faster to find.

What the KDC Actually Checks

The MIT krb5 KDC validates every TGS-REQ before it will issue a service ticket. The relevant function is check_tgs_tgt, which performs two checks:

1. The sname inside the PA-TGS-REQ must be a valid TGS principal (i.e., krbtgt/<REALM>).
2. The second component of that TGS principal must match the realm specified in the KDC-REQ-BODY.

If either check fails, the KDC returns KRB_AP_ERR_NOT_US with the status string BAD TGS SERVER NAME or BAD TGS SERVER INSTANCE.

/*
 * Do some checks for a normal TGS-REQ (where the ticket service must be a TGS
 * principal).
 */
static int
check_tgs_tgt(kdc_realm_t *kdc_active_realm, krb5_kdc_req *req,
              krb5_ticket *tkt, const char **status)
{
    /* Make sure it's a TGS principal. */
    if (!krb5_is_tgs_principal(tkt->server)) {
        *status = "BAD TGS SERVER NAME";
        return KRB_AP_ERR_NOT_US;
    }
    /* TGS principal second component must match service realm. */
    if (!data_eq(*krb5_princ_component(kdc_context, tkt->server, 1),
                 *krb5_princ_realm(kdc_context, req->server))) {
        *status = "BAD TGS SERVER INSTANCE";
        return KRB_AP_ERR_NOT_US;
    }
    return 0;
}

In plain terms, the KDC is asking: “Is the ticket you’re presenting actually a TGT for my realm?” If the answer is no, the request is rejected.

Common Root Causes

Most of the time the mismatch is not a Kerberos bug. It is a configuration or environment issue. The usual suspects:

• Bad name-to-IP mapping. The client resolves the KDC hostname to the wrong IP address, so it talks to a KDC in a different realm than the one that issued the TGT.
• Decryption failure. The target computer cannot decrypt the Kerberos authentication data sent by the client, often due to a clock skew greater than five minutes or a mismatched key.
• Missing or wrong SPN. The KDC or client cannot find the domain to look up the source Service Principal Name, so it falls back to an incorrect realm.
• Modified encrypted frames. Hardware (including network devices such as load balancers or firewalls), software, or an attacker altered the encrypted Kerberos frames in transit, corrupting the principal data.

Quick Troubleshooting Steps

1. Confirm the client and KDC clocks are synchronized (NTP) and within five minutes of each other.
2. Verify DNS: nslookup <kdc-hostname> should return the IP of the correct KDC.
3. Check the KDC log for the exact status string (BAD TGS SERVER NAME vs. BAD TGS SERVER INSTANCE) to narrow down which check failed.
4. Use klist -e on the client to inspect the TGT and confirm the realm matches the KDC realm.
5. If a network device sits between client and KDC, capture traffic with tcpdump and confirm the Kerberos packets are not being altered.

References

• MIT Kerberos 5 documentation: krb5_is_tgs_principal and check_tgs_tgt source in kdc/kdc_util.c.
• RFC 4120 (Kerberos V5), Section 5.4.1, for the TGS-REQ message structure.

• Security
• Technology

• Kerberos
• Troubleshooting
• Active-Directory