Application servers¶

If you need to install the Kerberos V5 programs on an application server, please refer to the Kerberos V5 Installation Guide. Once you have installed the software, you need to add that host to the Kerberos database (see Adding, modifying and deleting principals), and generate a keytab for that host, that contains the host’s key. You also need to make sure the host’s clock is within your maximum clock skew of the KDCs.

Keytabs¶

A keytab is a host’s copy of its own keylist, which is analogous to a user’s password. An application server that needs to authenticate itself to the KDC has to have a keytab that contains its own principal and key. Just as it is important for users to protect their passwords, it is equally important for hosts to protect their keytabs. You should always store keytab files on local disk, and make them readable only by root, and you should never send a keytab file over a network in the clear. Ideally, you should run the kadmin command to extract a keytab on the host on which the keytab is to reside.

Adding principals to keytabs¶

To generate a keytab, or to add a principal to an existing keytab, use the ktadd command from kadmin.

ktadd¶

ktadd [options] principal

ktadd [options] -glob princ-exp

Adds a principal, or all principals matching princ-exp, to a keytab file. Each principal’s keys are randomized in the process. The rules for princ-exp are described in the list_principals command.

This command requires the inquire and changepw privileges. With the -glob form, it also requires the list privilege.

The options are:

-k[eytab] keytab: Use keytab as the keytab file. Otherwise, the default keytab is used.
-e enc:salt,…: Uses the specified keysalt list for setting the new keys of the principal. See Keysalt lists in kdc.conf for a list of possible values.
-q: Display less verbose information.
-norandkey: Do not randomize the keys. The keys and their version numbers stay unchanged. This option cannot be specified in combination with the -e option.

An entry for each of the principal’s unique encryption types is added, ignoring multiple keys with the same encryption type but different salt types.

Alias: xst

Example:

kadmin: ktadd -k /tmp/foo-new-keytab host/foo.mit.edu
Entry for principal host/foo.mit.edu@ATHENA.MIT.EDU with kvno 3,
     encryption type aes256-cts-hmac-sha1-96 added to keytab
     FILE:/tmp/foo-new-keytab
kadmin:

Examples¶

Here is a sample session, using configuration files that enable only AES encryption:

kadmin: ktadd host/daffodil.mit.edu@ATHENA.MIT.EDU
Entry for principal host/daffodil.mit.edu with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab
Entry for principal host/daffodil.mit.edu with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab
kadmin:

Removing principals from keytabs¶

To remove a principal from an existing keytab, use the kadmin ktremove command.

ktremove¶

ktremove [options] principal [kvno | all | old]

Removes entries for the specified principal from a keytab. Requires no permissions, since this does not require database access.

If the string “all” is specified, all entries for that principal are removed; if the string “old” is specified, all entries for that principal except those with the highest kvno are removed. Otherwise, the value specified is parsed as an integer, and all entries whose kvno match that integer are removed.

The options are:

-k[eytab] keytab: Use keytab as the keytab file. Otherwise, the default keytab is used.
-q: Display less verbose information.

Alias: ktrem

Example:

kadmin: ktremove kadmin/admin all
Entry for principal kadmin/admin with kvno 3 removed from keytab
     FILE:/etc/krb5.keytab
kadmin:

Using a keytab to acquire client credentials¶

While keytabs are ordinarily used to accept credentials from clients, they can also be used to acquire initial credentials, allowing one service to authenticate to another.

To manually obtain credentials using a keytab, use the kinit -k option, together with the -t option if the keytab is not in the default location.

Beginning with release 1.11, GSSAPI applications can be configured to automatically obtain initial credentials from a keytab as needed. The recommended configuration is as follows:

Create a keytab containing a single entry for the desired client identity.
Place the keytab in a location readable by the service, and set the KRB5_CLIENT_KTNAME environment variable to its filename. Alternatively, use the default_client_keytab_name profile variable in [libdefaults], or use the default location of FILE:/etc/krb5/user/%{euid}/client.keytab.
Set KRB5CCNAME to a filename writable by the service, which will not be used for any other purpose. Do not manually obtain credentials at this location. (Another credential cache type besides FILE can be used if desired, as long the cache will not conflict with another use. A MEMORY cache can be used if the service runs as a long-lived process. See Credential cache for details.)
Start the service. When it authenticates using GSSAPI, it will automatically obtain credentials from the client keytab into the specified credential cache, and refresh them before they expire.

Clock Skew¶

A Kerberos application server host must keep its clock synchronized or it will reject authentication requests from clients. Modern operating systems typically provide a facility to maintain the correct time; make sure it is enabled. This is especially important on virtual machines, where clocks tend to drift more rapidly than normal machine clocks.

The default allowable clock skew is controlled by the clockskew variable in [libdefaults].

Getting DNS information correct¶

Several aspects of Kerberos rely on name service. When a hostname is used to name a service, clients may canonicalize the hostname using forward and possibly reverse name resolution. The result of this canonicalization must match the principal entry in the host’s keytab, or authentication will fail. To work with all client canonicalization configurations, each host’s canonical name must be the fully-qualified host name (including the domain), and each host’s IP address must reverse-resolve to the canonical name.

Configuration of hostnames varies by operating system. On the application server itself, canonicalization will typically use the /etc/hosts file rather than the DNS. Ensure that the line for the server’s hostname is in the following form:

IP address      fully-qualified hostname        aliases

Here is a sample /etc/hosts file:

# this is a comment
127.0.0.1      localhost localhost.mit.edu
10.0.0.6       daffodil.mit.edu daffodil trillium wake-robin

The output of klist -k for this example host should look like:

viola# klist -k
Keytab name: /etc/krb5.keytab
KVNO Principal
---- ------------------------------------------------------------
   2 host/daffodil.mit.edu@ATHENA.MIT.EDU

If you were to ssh to this host with a fresh credentials cache (ticket file), and then klist, the output should list a service principal of host/daffodil.mit.edu@ATHENA.MIT.EDU.

Configuring your firewall to work with Kerberos V5¶

If you need off-site users to be able to get Kerberos tickets in your realm, they must be able to get to your KDC. This requires either that you have a replica KDC outside your firewall, or that you configure your firewall to allow UDP requests into at least one of your KDCs, on whichever port the KDC is running. (The default is port 88; other ports may be specified in the KDC’s kdc.conf file.) Similarly, if you need off-site users to be able to change their passwords in your realm, they must be able to get to your Kerberos admin server on the kpasswd port (which defaults to 464). If you need off-site users to be able to administer your Kerberos realm, they must be able to get to your Kerberos admin server on the administrative port (which defaults to 749).

If your on-site users inside your firewall will need to get to KDCs in other realms, you will also need to configure your firewall to allow outgoing TCP and UDP requests to port 88, and to port 464 to allow password changes. If your on-site users inside your firewall will need to get to Kerberos admin servers in other realms, you will also need to allow outgoing TCP and UDP requests to port 749.

If any of your KDCs are outside your firewall, you will need to allow kprop requests to get through to the remote KDC. kprop uses the krb5_prop service on port 754 (tcp).

The book UNIX System Security, by David Curry, is a good starting point for learning to configure firewalls.

MIT Kerberos Documentation