RJ Systems
Linux System Administration
Home Tech Linux Links Consulting







Valid XHTML 1.0!

Valid CSS!

IPv6 test

MIT Kerberos V slave on Debian lenny

Introduction

Even for relatively small networks, a certralized authentication system has obvious advantages, but care should also be taken to offset the risk of a single point of failure. For this reason, an MIT Kerberos V master Key Distribution Center (KDC) can support one or more slave KDCs, which are read-only copies of the master. They offer much of the same functionality as a master KDC, but without the ability to perform administrative tasks. A master KDC with at least one slave is the recommended minimum.

This example builds on a previous one in which an MIT Kerberos V master KDC and administration server was installed on a host, called kdc1.example.com, running Debian 5.0 (lenny). If followed properly, this step-by-step process should produce a new slave KDC. The system relies heavily on timestamps, so reasonably accurate time synchronization among all participating hosts is essential.

Before the actual Kerberos installation process can begin, it will first be necessary to install Debian lenny on a new host called kdc2.example.com. A DNS server must also be available on the network with a zone file to which forward and reverse mappings can be added for this new host. After the initial installation of the operating system, make sure these packages are installed as well:

~# apt-get install ssh ntp ntpdate xinetd nmap

After installing them, edit /etc/ntp.conf so that the new host synchronizes to a common NTP server (preferably a local one) and edit /etc/default/ntpdate to do the same. Now the installation process for the MIT Kerberos V slave KDC can begin:


1. Kerberos client install

First, run the following command to test if the MIT Kerberos V server installed previously is available on the network:

~# nmap kdc1.example.com

This should be among the results:

PORT    STATE SERVICE
749/tcp open  kerberos-adm
754/tcp open  krb_prop

If there is a problem, fix it first. If not, continue by installing this package:

~# apt-get install krb5-user

A total of three packages are installed as a result, including two dependencies:

krb5-config            1.22                             Configuration files for Kerberos Version 5
krb5-user              1.6.dfsg.4~beta1-5lenny2         Basic programs to authenticate using MIT Kerberos
libkadm55              1.6.dfsg.4~beta1-5lenny2         MIT Kerberos administration runtime libraries

During the installation, a few questions are asked regarding the krb5-config package that should be answered as follows:

Kerberos servers for your realm: kdc1.example.com
Administrative server for your Kerberos realm: krb.example.com

2. Host princ & keytab

Use kadmin to login to the administration server (with password Lampropeltis) and create a new principal for this host, as well as a local keytab file:

~# kadmin -p admin
Authenticating as principal admin with password.
Password for admin@EXAMPLE.COM: Lampropeltis
kadmin:  addprinc -randkey host/kdc2.example.com
WARNING: no policy specified for host/kdc2.example.com@EXAMPLE.COM; 
defaulting to no policy
Principal "host/kdc2.example.com@EXAMPLE.COM" created.
kadmin:  ktadd host/kdc2.example.com
Entry for principal host/kdc2.example.com with kvno 3, encryption type 
AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab 
WRFILE:/etc/krb5.keytab.
Entry for principal host/kdc2.example.com with kvno 3, encryption type 
ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/kdc2.example.com with kvno 3, encryption type 
Triple DES cbc mode with HMAC/sha1 added to keytab 
WRFILE:/etc/krb5.keytab.
Entry for principal host/kdc2.example.com with kvno 3, encryption type 
DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
kadmin:  q
~# _

The -randkey switch is used because a machine cannot enter a password. By default, Kerberos saves its keys in /etc/krb5.keytab, so when kadmin is run from the target host to create those keys, the keytab file will automatically be saved in the right place. Use the klist -ke command to list the keys in the local keytab file.


3. Kerberos server install

On kdc2, install KDC services for the slave system:

~# apt-get install krb5-kdc

In this case, it is also the only package that is installed:

krb5-kdc         1.6.dfsg.4~beta1-5lenny2        MIT Kerberos key server (KDC)

Following this automated configuration sequence for the package, two familiar problems appear: first, a comment is displayed to inform xinetd users that manual conversion to xinetd format is necessary for a hashed-out kpropd entry that has been added to /etc/inetd.conf. This is for the Kerberos V database propagation daemon, which is required on KDC slave servers. Fix it now by simply creating a file called /etc/xinetd.d/krb_prop with the following contents:

service krb_prop
{
        disable         = no
        socket_type     = stream
        protocol        = tcp
        user            = root
        wait            = no
        server          = /usr/sbin/kpropd
}

After saving this file, restart xinetd:

~# /etc/init.d/xinetd restart

Issue the following command to display the system's open TCP and UDP ports:

~# nmap kdc2.example.com

What is important now is that kpropd is available, so the results should include:

PORT    STATE         SERVICE
754/tcp open          krb_prop

The second problem that occurs after installing the KDC is that it will not start, but this is because the database file for it (/var/lib/krb5kdc/principal) does not yet exist. This issue will be addressed later on.


4. Propagation ACL

On both kdc1 and kdc2, create a file called /etc/krb5kdc/kpropd.acl and add to it the following lines:

host/kdc1.example.com@EXAMPLE.COM
host/kdc2.example.com@EXAMPLE.COM

This file must contain a list of all host principals of the KDCs that are included in the realm. Therefore, kdc1 is included. In this way, the master and all of the slaves will each have a complete list of all the KDCs in the realm.


5. Database propagation

On the new host, kdc2, there is as yet no KDC database. A new one must be created, but not with a new realm being created at the same time, such as with the krb5_newrealm command that was used on kdc1 earlier. Instead, create an empty database with this command:

~# kdb5_util create
Loading random data
Initializing database '/var/lib/krb5kdc/principal' for realm 
'EXAMPLE.COM', master key name 'K/M@EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: adamanteus
Re-enter KDC database master key to verify: adamanteus
~# _

Indeed, the same KDC database master key password that was used for kdc1adamanteus − is used here as well. This is to avoid a bug. It should be possible to perform the next two commands without it, but that results in an error. With Debian 6.0 (squeeze) this is no longer be necessary.

Edit /etc/krb5kdc/kdc.conf and modify two options in the [realms] section regarding ticket lifetime to match the same values used on the master KDC:

max_life = 1d 0h 0m 0s
max_renewable_life = 90d 0h 0m 0s

Now on kdc1, create a dump of the KDC database:

root@kdc1:~# kdb5_util dump /var/lib/krb5kdc/slave_datatrans

Then, still on kdc1, use the kprop command, which will look for the above dump file, to propagate the database to kdc2:

root@kdc1:~# kprop kdc2.example.com
Database propagation to kdc2.example.com: SUCCEEDED
root@kdc1:~# _

Back on kdc2, create a stash file for the KDC database master key:

~# kdb5_util stash
kdb5_util: Cannot find/read stored master key while reading master key
kdb5_util: Warning: proceeding without master key
Enter KDC database master key: adamanteus
~# _

The password − adamanteus − is saved in the /etc/krb5kdc/stash file.

It is now possible to start the KDC slave server on kdc2.example.com:

~# /etc/init.d/krb5-kdc start

Issue the following command to display a list of all open TCP and UDP ports on the system:

~# nmap -sT -sU kdc2.example.com.

Note the trailing dot! Among the results should be:

PORT     STATE         SERVICE
88/udp   open|filtered kerberos-sec

This means the kerberos-sec (an alias for kerberos) service is now available.


6. Realm config file

Edit the Kerberos realm configuration file, /etc/krb5.conf. This file is initially created by the Debian installer and contains information about the realms of a number of famous institutions, but none of that is necessary in this case. Instead, replace its contents with this:

[libdefaults]
        default_realm = EXAMPLE.COM
        forwardable = true
        proxiable = true

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

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

[logging]
        kdc = FILE:/var/log/krb5/kdc.log
        admin_server = FILE:/var/log/krb5/kadmin.log
        default = FILE:/var/log/krb5/klib.log

See this section for a more detailed explanation of this file. The line "kdc = kdc2.example.com should then also be added to this configuration file on all the other hosts that are part of the same realm, or else they will not be able to make use of this server.

After /etc/krb5.conf has been saved, create the Kerberos log directory:

~# mkdir /var/log/krb5

Also, create a logrotate configuration file, /etc/logrotate.d/krb5, for the new Kerberos logs and give it the following contents:

/var/log/krb5/kadmin.log /var/log/krb5/kdc.log /var/log/krb5/klib.log {
        daily
        missingok
        rotate 7 
        compress
        delaycompress
        notifempty
}

7. Propagation script

The master KDC, kdc1.example.com, must regularly push its database out to the slaves to maintain synchronization. One way to do this is to create a script on kdc1, called /etc/cron.hourly/krb5-prop, to perform the database dump and propagation tasks that were described in step 5 on a regular basis. An example of such a script can be found in Garman (2003) on page 65. Here is a modified version of it that uses the example.com domain name and the Debian directory structure:

#!/bin/sh

# Distribute KDC database to slave servers
# Created by Jason Garman for use with MIT Kerberos 5
# Modified by Jaap Winius <jwinius@rjsystems.nl>

slavekdcs=kdc2.example.com

/usr/sbin/kdb5_util dump /var/lib/krb5kdc/slave_datatrans
error=$?

if [ $error -ne 0 ]; then

	echo "Kerberos database dump failed"
	echo "with exit code $error. Exciting."
	exit 1
fi

for kdc in $slavekdcs; do

	/usr/sbin/kprop $kdc > /dev/null
	error=$?

	if [ $error -ne 0 ]; then

		echo "Propagation of database to host $kdc"
		echo "failed with exit code $error."
	fi
done

exit 0

The main difference, however, between this version and the original, is that this script does not return anything in case of success, which is more in keeping with general Unix philosophy.

Additional slave hostnames, separated by spaces and enclosed between double quotes, can be added to this script by modifying the value of the slavekdcs variable, for instance like this:

slavekdcs="kdc2.example.com kdc3.example.com"

Do not forget to make the script executable:

~# chmod 755 /etc/cron.hourly/krb5-prop

8. Role reversal

Occasionally, the question arises of how best to maintain availability during, for example, a hardware upgrade. This is easily achieved by switching the role of the master KDC with one of its slaves. In the following instructions, kdc2.example.com will become the master and kdc1 its slave.

First, on kdc1, stop the Kerberos administration server process (kadmin):

~# /etc/init.d/krb5-admin-server stop

Then, still on kdc1, disable the propagation script and run it once more manually:

~# mv /etc/cron.hourly/krb5-prop ~/
~# ~/krb5-prop

Now, over on kdc2, install the Kerberos administration server:

~# apt-get install krb5-admin-server

Also, create a propagation script, /etc/cron.hourly/krb5-prop, just like the one above in step 8, except that the slave mentioned in it should be kdc1 instead of kdc2.

Next, still on kdc2, create a new file on kdc2, called /etc/krb5kdc/kadm5.acl, with the following contents:

*/admin *
admin *

This same file should be deleted from the previous master server, kdc1.

Finally, edit the alias (CNAME) record for krb in the example.com zone file and change it to refer to kdc2 instead of kdc1. The new master KDC will be available as soon as the DNS change becomes visible to the clients.


9. See also
10. Further reading
11. Sources
  • Garman J. 2003. Kerberos, The Definitive Guide. O'Reilly & Associates, Inc. ISBN-13 978-0-596-00403-3. 253 pp. See pages 63-65.
  • Massachusetts Institute of Technology. 1985-2007. Kerberos V5 System Administrator's Guide. HTML at the Massachusetts Institute of Technology (MIT).
  • Milicchio F, Gehrke WA. 2007. Distributed Services with OpenAFS. Springer-Verlag. ISBN-13 978-3-540-36633-1. 395 pp. See pages 45-51.


Last modified: 2010-10-25, 2:00

©2003-2014 RJ Systems. Permission is granted to copy, distribute and/or modify the
content of this page under the terms of the OpenContent License, version 1.0.