Hey there, let's dig into this Kerberos auth issue you're facing. That Server not found in Kerberos database error almost always ties to mismatched principals, hostname inconsistencies, or DNS problems. Let's break down the key checks and fixes step by step:

1. Fix Principal Case Sensitivity Issues #

Kerberos treats principal names as case-sensitive, especially the hostname component. Looking at your configs:

• Your ZooKeeper client uses kafka-d1.example.com (lowercase domain) for the connection string
• But your jaas.conf defines the ZooKeeper principal as zookeeper/kafka-d1.EXAMPLE.COM@EXAMPLE.COM (uppercase domain)

This mismatch means the client will request a principal matching the lowercase hostname, but your KDC only has the uppercase version registered. To resolve this:

• First, check what principals exist in your KDC with:

  kadmin.local -q "list_principals zookeeper/*"
  

• Ensure the principal in jaas.conf exactly matches what's in the KDC (case included). If needed, re-create the principal and keytab using the correct hostname case.

2. Validate Forward & Reverse DNS Resolution #

Kerberos relies heavily on accurate DNS mapping. If reverse DNS doesn't return the exact hostname in your principal, authentication will fail:

• Test forward resolution for your ZooKeeper host:

  nslookup kafka-d1.example.com
  

• Test reverse resolution for the returned IP:

  nslookup <IP_ADDRESS_FROM_PREVIOUS_STEP>
  

• Make sure the reverse lookup returns the exact hostname used in your Kerberos principal (case-sensitive). If not, update your DNS records or /etc/hosts file to align them.

3. Verify Keytab File Validity #

A corrupted or misconfigured keytab will also trigger this error. Check if your ZooKeeper keytab contains the correct principal:

klist -kt /etc/keytabs/zookeeper.keytab

Look for an entry matching zookeeper/kafka-d1.EXAMPLE.COM@EXAMPLE.COM with a valid expiration date. If it's missing, regenerate the keytab using:

kadmin.local -q "ktadd -k /etc/keytabs/zookeeper.keytab zookeeper/kafka-d1.EXAMPLE.COM@EXAMPLE.COM"

Repeat this check for your Kafka keytab to ensure it’s correctly linked to its principal.

4. Confirm krb5.conf Configuration #

Double-check your /etc/krb5.conf to eliminate typos or misconfigurations:

• Ensure default_realm is set to EXAMPLE.COM (matches your principal's realm)
• Verify the [realms] section points to your active KDC and admin server:

  [realms]
  EXAMPLE.COM = {
      kdc = kdc.example.com
      admin_server = kdc.example.com
  }
  

5. Test Kerberos Authentication Directly #

Isolate the issue by testing if you can obtain a ticket for the ZooKeeper principal using its keytab:

kinit -kt /etc/keytabs/zookeeper.keytab zookeeper/kafka-d1.EXAMPLE.COM@EXAMPLE.COM

If this command fails, the problem lies with the principal/keytab/KDC setup—not Kafka or ZooKeeper. Resolve this first before restarting your services.

After applying these fixes, restart both ZooKeeper and Kafka, then check the logs again to see if the authentication error is resolved.

内容的提问来源于stack exchange，提问作者Ahshan Md