Alternate KRB5.conf Location

Luke Hebert

- 2 minutes read - 264 words

A stale krb5.conf bundled with the JRE can silently shadow your system configuration and break Kerberos authentication for Java applications. This post walks through how the JRE resolves krb5.conf, how to override that order with an environment variable or system property, and how to verify the result.

How Java Resolves krb5.conf

The resolution order is:

  1. jre/lib/security/krb5.conf (bundled with the JRE)
  2. The path specified by the KRB5_CONFIG environment variable
  3. /etc/krb5.conf (system default)

Because step 1 wins, a stale or incorrect file shipped with the JRE can silently shadow your system configuration.

Pointing Java at an Alternate krb5.conf

The simplest fix is to export KRB5_CONFIG before the JVM starts:

export KRB5_CONFIG=/path/to/alt/krb5.conf
java -jar myapp.jar

You can also set it as a JVM system property, which is handy when you cannot control the environment (for example, inside a container):

java -Djava.security.krb5.conf=/path/to/alt/krb5.conf -jar myapp.jar
Important

The KRB5_CONFIG environment variable and the java.security.krb5.conf system property both take precedence over the JRE-bundled file. If both are set, the system property wins.

Quick Checklist

  • Confirm which file Java is actually reading: run java -Dsun.security.krb5.debug=true and watch the debug output for the resolved path.
  • Make sure the alternate file has valid [libdefaults], [realms], and [domain_realm] sections.
  • If you are running inside Docker or Kubernetes, set KRB5_CONFIG in the container environment or as a ConfigMap mount rather than editing the image.

Verifying the Configuration

A quick sanity check from the command line:

kinit -k -t /path/to/keytab principal@REALM
klist

If kinit succeeds against the KDC defined in your alternate file, the Java application should resolve the same realm and ticket-granting service.