CLI Kerberos Authentication

The openLooKeng Command Line Interface can connect to a openLooKeng coordinator that has Kerberos authentication enabled.

Environment Configuration

Kerberos Services

You will need a Kerberos KDC running on a node that the client can reach over the network. The KDC is responsible for authenticating principals and issuing session keys that can be used with Kerberos-enabled services. KDCs typically run on port 88, which is the IANA-assigned port for Kerberos.

MIT Kerberos Configuration

Kerberos needs to be configured on the client. At a minimum, there needs to be a kdc entry in the [realms] section of the /etc/krb5.conf file. You may also want to include an admin_server entry and ensure that the client can reach the Kerberos admin server on port 749.

  1. [realms]
  2. openlookeng.EXAMPLE.COM = {
  3. kdc = kdc.example.com
  4. admin_server = kdc.example.com
  5. }
  6. [domain_realm]
  7. .openlookeng.example.com = OPENLOOKENG.EXAMPLE.COM
  8. openlookeng.example.com = OPENLOOKENG.EXAMPLE.COM

The complete documentation for krb5.conf is hosted by the MIT Kerberos Project. If you are using a different implementation of the Kerberos protocol, you will need to adapt the configuration to your environment.

Kerberos Principals and Keytab Files

Each user who connects to the openLooKeng coordinator needs a Kerberos principal. You will need to create these users in Kerberos using kadmin.

Additionally, each user needs a keytab file. The keytab file can be created using kadmin after you create the principal.

  1. kadmin
  2. > addprinc -randkey someuser@EXAMPLE.COM
  3. > ktadd -k /home/someuser/someuser.keytab someuser@EXAMPLE.COM

Note

Running ktadd randomizes the principal’s keys. If you have just created the principal, this does not matter. If the principal already exists, and if existing users or services rely on being able to authenticate using a password or a keytab, use the -norandkey option to ktadd.

Java Cryptography Extension Policy Files

The Java Runtime Environment is shipped with policy files that limit the strength of the cryptographic keys that can be used. Kerberos, by default, uses keys that are larger than those supported by the included policy files. There are two possible solutions to the problem:

  • Update the JCE policy files.
  • Configure Kerberos to use reduced-strength keys.

Of the two options, updating the JCE policy files is recommended. The JCE policy files can be downloaded from Oracle. Note that the JCE policy files vary based on the major version of Java you are running. Java 6 policy files will not work with Java 8, for example.

The Java 8 policy files are available here. Instructions for installing the policy files are included in a README file in the ZIP archive. You will need administrative access to install the policy files if you are installing them in a system JRE.

Java Keystore File for TLS

Access to the openLooKeng coordinator must be through https when using Kerberos authentication. The openLooKeng coordinator uses a Java Keystore file for its TLS configuration. This file can be copied to the client machine and used for its configuration.

openLooKeng CLI execution

In addition to the options that are required when connecting to a openLooKeng coordinator that does not require Kerberos authentication, invoking the CLI with Kerberos support enabled requires a number of additional command line options. The simplest way to invoke the CLI is with a wrapper script.

  1. #!/bin/bash
  2. ./openlk-cli \
  3. --server https://openlookeng-coordinator.example.com:7778 \
  4. --krb5-config-path /etc/krb5.conf \
  5. --krb5-principal someuser@EXAMPLE.COM \
  6. --krb5-keytab-path /home/someuser/someuser.keytab \
  7. --krb5-remote-service-name openLooKeng \
  8. --keystore-path /tmp/openLooKeng.jks \
  9. --keystore-password password \
  10. --catalog <catalog> \
  11. --schema <schema>
OptionDescription
—serverThe address and port of the openLooKeng coordinator. The port must be set to the port the openLooKeng coordinator is listening for HTTPS connections on.
—krb5-config-pathKerberos configuration file.
—krb5-principalThe principal to use when authenticating to the coordinator.
—krb5-keytab-pathThe location of the the keytab that can be used to authenticate the principal specified by —krb5-principal
—krb5-remote-service-nameopenLooKeng coordinator Kerberos service name.
—keystore-pathThe location of the Java Keystore file that will be used to secure TLS.
—keystore-passwordThe password for the keystore. This must match the password you specified when creating the keystore.

Troubleshooting

Many of the same steps that can be used when troubleshooting the openLooKeng coordinator apply to troubleshooting the CLI.

Additional Kerberos Debugging Information

You can enable additional Kerberos debugging information for the openLooKeng CLI process by passing -Dsun.security.krb5.debug=true as a JVM argument when starting the CLI process. Doing so requires invoking the CLI JAR via java instead of running the self-executable JAR directly. The self-executable jar file cannot pass the option to the JVM.

  1. #!/bin/bash
  2. java \
  3. -Dsun.security.krb5.debug=true \
  4. -jar hetu-cli-*-executable.jar \
  5. --server https://openlookeng-coordinator.example.com:7778 \
  6. --krb5-config-path /etc/krb5.conf \
  7. --krb5-principal someuser@EXAMPLE.COM \
  8. --krb5-keytab-path /home/someuser/someuser.keytab \
  9. --krb5-remote-service-name openLooKeng \
  10. --keystore-path /tmp/openLooKeng.jks \
  11. --keystore-password password \
  12. --catalog <catalog> \
  13. --schema <schema>

The additional resources listed in the documentation for setting up Kerberos authentication for the openLooKeng coordinator may be of help when interpreting the Kerberos debugging messages.