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.
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 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:
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.
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"
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