This section of the document describes the installation and configuration of the machines and software which will function as the KDCs. You may want to make some adjustments to the configurations suggested, but there are a few key points presented that are very important to remember when configuring your KDCs. So, if you do decide on an alternative configuration strategy make sure you understand the material presented here.

The machines will run the Kerberos daemon and store password and policy data. Therefore, it's very important to the security of the network that these servers remain secure. We should take every possible measure to prevent these servers from being compromised. Pay particular attention to the security advice given in this section.

The key points of that security advice are that you should dedicate hardware to providing Kerberos KDC service. You should physically secure that hardware, and you should harden GNU/Linux as much as possible on that hardware. If a KDC is compromised, your entire Kerberos infrastructure is compromised.

Kerberos service does not place a great demand on hardware and the Kerberos services have a capability for redundancy, therefore server hardware can be minimal. For the Kerberos servers which I've deployed I've used uniprocessor PIII machines with two hardware RAID 1 drives. These machines are meant to handle between forty and one hundred thousand authentications per day. While servers may be deployed with redundant NIC cards, having both cards active simultaneously should be avoided. Kerberos includes the IP of the KDC in tickets, therefore difficulties authenticating may occur if the KDC is contacted on multiple interfaces by a client during an authentication session.

It is important to note that Kerberos service should be run on dedicated hardware. Dedicating a machine to Kerberos means that only the Kerberos administrator will need to log in on those machines. It also means that no other services, except perhaps SSH, will be run on the machines. Since all of your users passwords are stored on the Kerberos servers, it is a good idea to limit access as much as possible to the hardware. Along with dedicating servers to Kerberos, you should also physically secure your servers as much as possible. For Kerberos servers, this may include locking the servers in a cabinet and having a dedicated terminal attached to them.

In order to take advantage of Kerberos' built in capability for redundancy, you must have at least two machines running as KDCs. Kerberos is designed to be deployed with one primary master server, and one or more secondary slave servers. You may have as many secondary servers as you would like.

The servers we're installing GNU/Linux on will be dedicated to the task of performing Kerberos service, therefore we can take some extra steps to secure them.

First, we'll only install software that is absolutely necessary for Kerberos service. This includes the base operating system and the Kerberos packages. We should not install X or any GUI applications. SSH is optional. SSH may be installed if you wish to be able to administer the servers remotely. However, the servers would be significantly more secure if you only provide login access to them through an attached terminal.

In Fedora Core based GNU/Linux, the packages required to provide Kerberos service are:

krb5-server
krb5-libs

Documentation and development libraries should not be installed on the KDC, since we do not want to use this machine for anything but the performance of KDC service.

The next step will be to make sure that no ports are open that do not need to be and that any necessary security patches that are needed are applied. The methodology to determining what security patches need to be applied is depended up what package management software is installed. To determine what ports the machine is currently listening on, the netstat command can be used. For example, on a machine which only ssh running we should see the following:

bash$ netstat -an | grep -i listen | less
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN

Finally, we'll configure the server to restrict access only to servers that need to talk to it for authentication. This should be done by editing /etc/hosts.allow and /etc/hosts.deny as well as with iptables.

Realm names are case sensitive and must be unique on your network. It is a standard best practice to use your second level domain name in all uppercase letters as your realm name. If you are setting up Kerberos for only a subnet rather than your entire network, you should use the trailing domain name of the subnet.

When determining your realm topology, you should take the overall structure of your organization into account. If your organization has one or more remote offices or independent sub groups, they may be best included under a separate realm. Kerberos realm topology should mirror system management topology rather than physical network topology.

Finally, legacy systems should also be taken into account. For example, legacy Kerberos deployments or existing network topology grouping which you wish to preserve (i.e. Windows NT domains).

If you are installing Kerberos on a network which already has Kerberos deployed in the overall network or in a subnet, you must avoid a realm name collision. The most common occurrence of deploying Kerberos on a network with a preexisting Kerberos installation occurs when working with a network that includes an IBM SP cluster. The best solution is to create a realm specifically for the SP cluster at third or high domain name level and then use a second level domain name for your primary Kerberos realm.

In this document, we'll use an example to help illustrate the design and configuration of an infrastructure. For our example, we'll use a mythical university which was founded to educate people with, and perform research in the area of, free content - Gnu University in Dublin, Ireland. The Gnu University Dublin example will include two Kerberos servers used to authenticate students and faculty. The TLD for the university is gnud.ie, therefore we'll use the Kerberos realm of GNUD.IE.

Now, you'll need to configure Kerberos, create an administrator, determine a policy, and initialize the Kerberos principal database.

The first step is to edit the /etc/krb5.conf configuration file. In this file you'll need to set your realm, expand on the realm definition by specifying the Kerberos servers, and finally setting the domain realm. For our example, this is done as follows:

default_realm = GNUD.IE

[realms]
 GNUD.IE = {
  kdc = kerberos1.gnud.ie:88
  kdc = kerberos2.gnud.ie:88
  admin_server = kerberos1.gnud.ie:749
  default_domain = gnud.ie
 }

[domain_realm]
 .gnud.ie = GNUD.IE
 gnud.ie = GNUD.IE

To initialize and create the Kerberos database, you must run the follow command:

{Kerberos1}bash# /usr/Kerberos/sbin/kdb5_util create -s

The -s flag tell the KDC to create a stash file to authenticate itself. You may also use a -r flag to specify a realm. Specifying a realm for the new database is only necessary if you have more than one realm defined in your krb5.conf file.

Kerberos will then ask you to set the master password for your Kerberos database. It is very important that you do not forget this password. You will not be able to administrate your server if you do not remember the master password.

Next on the KDC you must edit the acl file to grant administrative access. Typically, this file is located at /var/Kerberos/krb5kdc/kadm5.acl. If necessary, specify the acl file location in your kdc.conf file. The location of your kdc.conf file is specified in your /etc/krb5.conf file and defaults to /var/Kerberos/krb5kdc/kdc.conf. For our GNU University Dublin example, we'll modify the acl file to include the following contents:

*/admin@GNUD.IE     *

The meaning of those acl contents are that any account which ends with a /admin in the GNUD.IE realm is granted full access privileges.

Now that we've set up access for our administrative user, we need to create that administrative user. You can do this with the kadmin.local command from a root shell on the KDC, using the addprinc sub command. The standard is to name the administrative account admin. For the Gnu University Dublin Kerberos Administrator, the following command would accomplish this:

{Kerberos1}bash# /usr/Kerberos/sbin/kadmin.local -q "addprinc admin/admin"

The daemons that must run on the server are krb5kdc and kadmin. If necessary, krb524 may also be run to provide backward compatibility to Kerberos 4 clients. However, before starting krb524 remember our security warning about Kerberos V4 and be sure that you really need to provide that functionality. On the KDCs krb5kdc and kadmin should be configured to start automatically by turning them on with the chkconfig command.

{Kerberos1}bash# /sbin/chkconfig krb5kdc on
{Kerberos1}bash# /sbin/chkconfig kadmin on

Finally, we can start them up manually, with the following command:

{Kerberos1}bash# /etc/rc.d/init.d/krb5kdc start
{Kerberos1}bash# /etc/rc.d/init.d/kadmin start

and we have a working KDC.

You can create the first user principal in Kerberos with the following command:

{Kerberos1}bash# kadmin.local
{Kerberos1}kadmin.local: addprinc <username>

A script could be written to create principals in bulk if you have a large number of account which you will be supporting with Kerberos.