skip to content

What does krb5.conf contain for a Kafka deployment, and how do clock skew and DNS affect GSSAPI authentication?

level: middleimportance: should knowfreq 32%

answer

  1. [libdefaults] default_realm + enctypes
  2. [realms] kdc/admin_server; [domain_realm] DNS->realm
  3. Clock skew >5min = 'Clock skew too great'
  4. FQDN forward/reverse = 'Server not found'
  5. udp_preference_limit=1 for big AD tickets

basics

~10 s

krb5.conf tells the JVM the default realm, where the KDCs are, and how DNS domains map to realms. Kerberos also requires synchronized clocks (within ~5 minutes) and consistent forward/reverse DNS, or authentication fails.

solid answer

~40 s

krb5.conf is the Kerberos client config Kafka reads via -Djava.security.krb5.conf. Its [libdefaults] sets default_realm and often default_tkt_enctypes/default_tgs_enctypes, ticket_lifetime, renew_lifetime, and dns_lookup_kdc. [realms] lists each realm with its kdc and admin_server hosts. [domain_realm] maps DNS suffixes/hosts to realms so the client can derive the broker's realm from its hostname. Two cross-cutting requirements: clock skew between client, broker, and KDC must stay under the configured clockskew (default ~300s) or you get 'Clock skew too great' — keep NTP tight. And DNS must be consistent: the broker's FQDN must resolve forward and reverse to match its SPN kafka/<fqdn>, because Kerberos canonicalizes hostnames into the service principal. Misconfigured rdns or short hostnames produce 'Server not found in Kerberos database'.

go deeper

for a junior

Know krb5.conf points to the realm and KDC, and that clocks must be in sync.

for a middle

Read/write the [libdefaults], [realms], [domain_realm] sections and connect common errors to clock skew and DNS.

for a senior

Diagnose enctype, rdns, and UDP/TCP issues and tune krb5.conf for AD-scale tickets.

for a principal

Standardize krb5.conf, NTP, and DNS hygiene across a fleet and design cross-realm [capaths].

## What krb5.conf is A plain-text config (typically `/etc/krb5.conf`) that any Kerberos client — including the JVM running Kafka — reads to locate KDCs and understand realms. Kafka points the JVM at it with `-Djava.security.krb5.conf=/etc/krb5.conf`. ## Main sections - **`[libdefaults]`**: `default_realm = EXAMPLE.COM`; optional `dns_lookup_kdc = true` to find KDCs via DNS SRV records; `ticket_lifetime` and `renew_lifetime` defaults; `default_tkt_enctypes`/`default_tgs_enctypes`/`permitted_enctypes` controlling allowed encryption types (align with the KDC, prefer AES); `clockskew` tolerance (default ~300 seconds); `udp_preference_limit` (set to 1 to force TCP when tickets are large, common with AD PAC). - **`[realms]`**: per realm, the `kdc = ...` host(s) and `admin_server = ...`. Multiple kdc lines provide failover. - **`[domain_realm]`**: maps DNS names to realms, e.g. `.example.com = EXAMPLE.COM` and `kafka1.example.com = EXAMPLE.COM`. This is how the client decides which realm a given broker host belongs to. - **`[capaths]`**: needed for cross-realm trusts to describe the authentication path between realms. ## Why clocks matter Kerberos tickets carry timestamps and are valid only within a window. If client, broker, and KDC clocks differ by more than the allowed **clockskew** (commonly 5 minutes; AD default ~5 min too), the KDC or broker rejects the ticket with **'Clock skew too great.'** This is why NTP/chrony on every node is mandatory. ## Why DNS matters Kerberos constructs the broker's **service principal** from its hostname (e.g. `kafka/[email protected]`). The JVM may canonicalize the host via DNS. If forward and reverse DNS disagree, or clients use a short name while the SPN uses an FQDN, the requested ticket name will not match any principal in the KDC, yielding **'Server not found in Kerberos database.'** Best practice: use FQDNs everywhere, ensure consistent forward/reverse records, and set `rdns = false` in `[libdefaults]` if reverse lookups are unreliable. ## Other gotchas - `dns_lookup_kdc = true` lets the client find KDCs via SRV records but adds a DNS dependency; many shops hardcode `kdc =` instead. - Large AD tickets (with PAC) can exceed UDP limits; `udp_preference_limit = 1` forces TCP. - Enctype mismatches between krb5.conf and the KDC produce 'KDC has no support for encryption type.' ## Quick triage checklist 1. Clocks in sync? (`date`, NTP) -> fixes 'Clock skew too great'. 2. FQDN forward/reverse consistent and matching the SPN? -> fixes 'Server not found.' 3. Enctypes overlap with KDC? -> fixes 'no support for encryption type.' 4. krb5.conf path actually passed to the JVM? (`-Djava.security.krb5.conf`).

  • A client reports 'Clock skew too great.' What do you check first?
    Time synchronization across client, broker, and KDC — Kerberos rejects tickets when clocks differ beyond ~5 minutes; fix NTP/chrony.
  • Why might forcing TCP (udp_preference_limit=1) be needed with Active Directory?
    AD tickets include a large PAC that can exceed UDP packet limits; forcing TCP avoids truncated/failed ticket transport.

saying these in an interview costs you the question

  • Ignoring NTP and blaming Kafka config when the real issue is clock skew
  • Using short hostnames when the SPN is an FQDN
  • Assuming krb5.conf is read automatically without -Djava.security.krb5.conf
  • Mixing realm case (realms are conventionally uppercase)

context

resolving links…