Docker container generator for a Heimdal Kerberos 5 KDC.

The intension here is to ease the first steps with Kerberos while also allowing a customized, automated setup for development or test integration. Usable on plain Linux as well as on OSX.

• Docker
• jq 1.4

• Heimdal Kerberos 5

• boot2docker

The default configuration is likely to be fine for your first steps, validate it using the config command.

./kdc config

You will receive a list of relevant configuration information. The defaults are derived from your hosts' configuration to allow for a quick test setup.

Example output: ./kdc config

System
  fqdn:      hostname.domain.name
KDC
  nat:       127.0.0.1
  port:      48088
Kerberos
  domain:    domain.name
  realm:     DOMAIN.NAME
  principal: tillt/[email protected], password: matilda

./kdc build

This will render the image which is based on plain ubuntu 14.04. Additionally the packages heimdal-kdc as well as libsasl2-modules-gssapi-heimdal are installed. The latter is useful only if you extend this container image by further applications making use of Kerberos authentication via SASL2's GSSAPI.

./kdc start

On OSX, this step starts by setting up the VM (via boot2docker). Then, on all host systems, the container is started in detached mode, allowing you to keep on working with this shell without having to fork another process. The container name is directly derived from the hostname supplied via the configuration (see Configuration).

docker exec -it kdc tail -f /var/log/heimdal-kdc.log

./kdc test

On OSX, this first checks if the VM is active. Then, on all hosts systems, a network connection to the KDC is attempted.

$(./kdc shellinit)

A Kerberos client needs access to a configuration file. To prevent having to edit the system wide configuration file (/etc/krb5.conf) a local, minimal version is rendered and supplied once the container has gotten started. Additionally, the keytab also gets exported and hence needs to be accessible for clients making use of password-less authentication. To make use of the files, environment variables that are interpreted by Kerberos clients are prepared.

kinit tillt/[email protected]

Password: matilda

klist

On OSX you could also use the Ticket Viewer to check the details of the issued ticket (open "/System/Library/CoreServices/Ticket Viewer.app").

Example output: klist

Credentials cache: API:42926CE1-63E2-4C66-B2D7-00B2F198182F
        Principal: tillt/[email protected]

  Issued                Expires               Principal
Nov 26 11:06:25 2014  Nov 26 21:06:25 2014  krbtgt/[email protected]

kdestroy

ktutil --keytab=krb5.keytab list

Example output: ktutil --keytab=krb5.keytab list

krb5.keytab:

Vno  Type                     Principal                              Aliases
  1  aes256-cts-hmac-sha1-96  tillt/[email protected]
  1  des3-cbc-sha1            tillt/[email protected]
  1  arcfour-hmac-md5         tillt/[email protected]

kinit -kt krb5.keytab tillt/[email protected]

klist

[...]

./kdc stop

This will stop the KDC server, stop and remove the container and additionally remove the temporary keytab and configuration files.

You may use environment variables and/or a JSON configuration file for customizing the setup. The default filename for the JSON file is kdc.json but may be configured by the environment variable KDC_CONFIG.

The default configuration is most likely good enough for your first experiments.

Note: using a configuration file allows setting up multiple principals (via principals[ ].id).

Note: using a configuration file allows setting up multiple passwords (via principals[ ].password).

Note: when no principals are defined via configuration file, KDC_CLIENT is used to create a full service principal (schema: KDC_PRINCIPAL / KDC_CLIENT . KDC_DOMAIN_NAME @ KDC_REALM_NAME ).

Note: this value gets overridden by the kdc script on OSX to allow for connecting to the boot2docker VM. You shouldn't really need to override this in any case.

Note: it is common practice to simply use the domain-name but all capitalized for this.

templates/kdc.json

{
  "principals": [
    {
      "id": "tillt/[email protected]",
      "password": "herbert"
    },
    {
      "id": "[email protected]",
      "password": "herbert"
    }
  ],
  "domain": "example.com",
  "realm": "EXAMPLE.COM",
  "ip": "127.0.0.1",
  "port": 48088
}

./kdc start|stop|build|clean|config|shellinit

Builds the docker image.

Starts the container in detached mode while also producing a Kerberos configuration file (krb5.conf) as well as a Kerberos keytab (krb5.keytab) locally.

Note that the keytab is only readable/usable by the current user unless you change its access rights which is not recommended for production environments.

Stops the container and deletes krb5.conf as well as krb5.keytab.

Removes the docker image.

Shows relevant configuration information.

Checks if the KDC is reachable and accepting connections.

Renders the environment variables needed for using the KDC. KRB5_CONFIG points towards the temporary configuration file. KRB5_KTNAME points towards the temporary keytab file.

• strip down base image to squeeze out some space
• refactor code into something less convoluted
• allow for an admin server, not just the KDC

This script was inspired by some work of a co-worker of mine, Matthias Veit. Matthias did the hard work of finding out how to properly route docker ports on boot2docker hosts.

• Till Toenshoff (@ttoenshoff)