39.6 Configuring Kerberos Clients

Once the supporting infrastructure is in place (DNS, NTP) and the KDC has been properly configured and started, configure the clients machines. You can either use YaST to configure a Kerberos client or use one of the two manual approaches described below.

39.6.1 Configuring a Kerberos Client with YaST

Rather than manually editing all relevant configuration files when configuring a Kerberos client, let YaST do the job for you. You can either perform the client configuration during the installation of your machine or in the installed system:

  1. Log in as root and select Network Services > Kerberos Client.

  2. Select Use Kerberos.

  3. To configure a DNS-based Kerberos client, proceed as follows:

    1. Confirm the Basic Kerberos Settings that are displayed.

    2. Click Advanced Settings to configure details on ticket-related issues, OpenSSH support, and time synchronization.

  4. To configure a static Kerberos client, proceed as follows:

    1. Set Default Domain, Default Realm, and KDC Server Address to the values that match your setup.

    2. Click Advanced Settings to configure details on ticket-related issues, OpenSSH support, and time synchronization.

Figure 39-2 YaST: Basic Configuration of a Kerberos Client

To configure ticket-related options in the Advanced Settings dialog, choose from the following options:

  • Specify the Default Ticket Lifetime and the Default Renewable Lifetime in days, hours, or minutes (using the units of measurement d, h, and m, with no blank space between the value and the unit).

  • To forward your complete identity to use your tickets on other hosts, select Forwardable.

  • Enable the transfer of certain tickets by selecting Proxiable.

  • Keep tickets available with a PAM module even after a session has ended by enabling Retained.

  • Enable Kerberos authentication support for your OpenSSH client by selecting the corresponding check box. The client then uses Kerberos tickets to authenticate with the SSH server.

  • Exclude a range of user accounts from using Kerberos authentication by providing a value for the Minimum UID that a user of this feature must have. For instance, you may want to exclude the system administrator (root).

  • Use Clock Skew to set a value for the allowable difference between the time stamps and your host's system time.

  • To keep the system time in sync with an NTP server, you can also set up the host as an NTP client by selecting NTP Configuration, which opens the YaST NTP client dialog that is described in Section 24.1, Configuring an NTP Client with YaST. After finishing the configuration, YaST performs all the necessary changes and the Kerberos client is ready for use.

Figure 39-3 YaST: Advanced Configuration of a Kerberos Client

39.6.2 Manually Configuring Kerberos Clients

When configuring Kerberos, there are basically two approaches you can take—static configuration in the /etc/krb5.conf file or dynamic configuration with DNS. With DNS configuration, Kerberos applications try to locate the KDC services using DNS records. With static configuration, add the hostnames of your KDC server to krb5.conf (and update the file whenever you move the KDC or reconfigure your realm in other ways).

DNS-based configuration is generally a lot more flexible and the amount of configuration work per machine is a lot less. However, it requires that your realm name is either the same as your DNS domain or a subdomain of it. Configuring Kerberos via DNS also creates a minor security issue—an attacker can seriously disrupt your infrastructure through your DNS (by shooting down the name server, spoofing DNS records, etc.). However, this amounts to a denial of service at most. A similar scenario applies to the static configuration case unless you enter IP addresses in krb5.conf instead of hostnames.

Static Configuration

One way to configure Kerberos is to edit the configuration file /etc/krb5.conf. The file installed by default contains various sample entries. Erase all of these entries before starting. krb5.conf is made up of several sections, each introduced by the section name included in brackets like [this].

To configure your Kerberos clients, add the following stanza to krb5.conf (where kdc.example.com is the hostname of the KDC): 

[libdefaults]
        default_realm = EXAMPLE.COM

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

The default_realm line sets the default realm for Kerberos applications. If you have several realms, just add additional statements to the [realms] section.

Also add a statement to this file that tells applications how to map hostnames to a realm. For example, when connecting to a remote host, the Kerberos library needs to know in which realm this host is located. This must be configured in the [domain_realms] section: 

[domain_realm]
        .example.com = EXAMPLE.COM
        www.foobar.com = EXAMPLE.COM

This tells the library that all hosts in the example.com DNS domains are in the EXAMPLE.COM Kerberos realm. In addition, one external host named www.foobar.com should also be considered a member of the EXAMPLE.COM realm.

DNS-Based Configuration

DNS-based Kerberos configuration makes heavy use of SRV records. See (RFC2052) A DNS RR for specifying the location of services at http://www.ietf.org. These records are not supported in earlier implementations of the BIND name server. At least BIND version 8 is required for this.

The name of an SRV record, as far as Kerberos is concerned, is always in the format _service._proto.realm, where realm is the Kerberos realm. Domain names in DNS are case insensitive, so case-sensitive Kerberos realms would break when using this configuration method. _service is a service name (different names are used when trying to contact the KDC or the password service, for example). _proto can be either _udp or _tcp, but not all services support both protocols.

The data portion of SRV resource records consists of a priority value, a weight, a port number, and a hostname. The priority defines the order in which hosts should be tried (lower values indicate a higher priority). The weight is there to support some sort of load balancing among servers of equal priority. You probably do not need any of this, so it is okay to set these to zero.

MIT Kerberos currently looks up the following names when looking for services:

_kerberos

This defines the location of the KDC daemon (the authentication and ticket granting server). Typical records look like this:

_kerberos._udp.EXAMPLE.COM.  IN  SRV    0 0 88 kdc.example.com. 
_kerberos._tcp.EXAMPLE.COM.  IN  SRV    0 0 88 kdc.example.com.
_kerberos-adm

This describes the location of the remote administration service. Typical records look like this:

_kerberos-adm._tcp.EXAMPLE.COM. IN  SRV    0 0 749 kdc.example.com.

Because kadmind does not support UDP, there should be no _udp record.

As with the static configuration file, there is a mechanism to inform clients that a specific host is in the EXAMPLE.COM realm, even if it is not part of the example.com DNS domain. This can be done by attaching a TXT record to _keberos.hostname, as shown here:

_keberos.www.foobar.com.  IN TXT "EXAMPLE.COM"

Adjusting the Clock Skew

The clock skew is the tolerance for accepting tickets with time stamps that do not exactly match the host's system clock. Usually, the clock skew is set to 300 seconds (five minutes). This means a ticket can have a time stamp somewhere between five minutes ago and five minutes in the future from the server's point of view.

When using NTP to synchronize all hosts, you can reduce this value to about one minute. The clock skew value can be set in /etc/krb5.conf like this: 

[libdefaults]
        clockskew = 120