Lost in the Realm: Kerberos Dropped the Map Again

Luke Hebert

- 2 minutes read - 365 words

When a Kerberos client returns the error “Server not found in Kerberos database,” it means the client was unable to obtain a service ticket for the requested SPN. The good news is that this error almost always traces back to one of four specific causes, and each one has a straightforward way to verify and fix.

Common Root Causes

  1. Reverse DNS is not set up correctly. The client resolves the server name to an IP address, then performs a reverse lookup to confirm the hostname. If the PTR record is missing or points to the wrong name, Kerberos will reject the ticket request. Verify with nslookup <server-ip> and confirm the PTR record matches the FQDN the client is using.

  2. A duplicate SPN exists in Active Directory. This is a frequent issue when Centrify (or a similar identity tool) is installed with its default configuration, which can register an extra SPN on the machine account. Other causes include manual SPN registration or a service being moved between servers without cleaning up the old entry. Use setspn -X to scan for duplicates, or query directly with setspn -T <domain> -Q <service>/<hostname>.

  3. Principals have not yet replicated to all domain controllers. If a new SPN was just registered, it may not have propagated to the DC the client happened to contact. Wait for replication (or force it with repadmin /syncall /APADT), then retry the connection.

  4. The domain_realm mapping is incorrect. The client’s Kerberos configuration (typically /etc/krb5.conf on Linux or the registry on Windows) maps a DNS domain to a Kerberos realm. If the mapping points to the wrong realm, the client will contact a KDC that does not know the requested SPN. Confirm the mapping with kinit -V or by inspecting the [domain_realm] section of krb5.conf.

Quick Verification Steps

  • Run kinit -V <user>@<REALM> to confirm the client can reach the correct KDC.
  • Check the server’s SPN registration: setspn -T <domain> -Q <service>/<hostname>.
  • Confirm forward and reverse DNS both resolve to the expected FQDN.
  • Review the domain_realm section in the client’s Kerberos config file.

Working through these four checks in order will resolve the vast majority of “Server not found” errors without needing to dig into deeper Kerberos internals.