RJ Systems
Linux System Administration
Home Tech Linux Links Consulting

Valid XHTML 1.0!

Valid CSS!

IPv6 test

MIT Kerberos V slave on Debian squeeze


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 6.0 (squeeze). 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 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 -sT -p T:749,754 kdc1.example.com

Starting Nmap 5.00 ( http://nmap.org ) at 2010-10-10 01:30 CEST
Interesting ports on kdc1.example.com (
749/tcp open  kerberos-adm
754/tcp open  krb_prop
MAC Address: 08:00:27:AB:13:C1 (Cadmus Computer Systems)

Nmap done: 1 IP address (1 host up) scanned in 0.20 seconds

If the the kerberos-adm and krb_prop services are not available as shown above, make sure that they are before continuing. Otherwise, install this package:

~# apt-get install krb5-user

A total of two packages are installed as a result, including one dependency:

krb5-config            2.2                         Configuration files for Kerberos Version 5
krb5-user              1.8.3+dfsg-1                Basic programs to authenticate using MIT Kerberos

During this install process, a few questions are asked regarding Kerberos authentication that should be answered as follows:

Default Kerberos version 5 realm: EXAMPLE.COM
Kerberos servers for your realm: kdc1.example.com
Administrative server for your Kerberos realm: krb.example.com

2. Realm config file

Replace 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, none of which is necessary here. Instead, add the following contents to the new file:

        default_realm = EXAMPLE.COM
        forwardable = true
        proxiable = true

        EXAMPLE.COM = {
                kdc = kdc2.example.com
                admin_server = krb.example.com

        .example.com = EXAMPLE.COM
        example.com = EXAMPLE.COM

        kdc = FILE:/var/log/krb5/kdc.log
        default = FILE:/var/log/krb5/kdc.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; if not they will be unable to make use of this server.

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

~# mkdir /var/log/krb5

To prevent the log file from growing too large, create a logrotate configuration file. Edit /etc/logrotate.d/krb5-kdc and give it the following contents:

/var/log/krb5/kdc.log {
	rotate 7
		/etc/init.d/krb5-kdc restart > /dev/null

3. 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 2, encryption type 
AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab 
Entry for principal host/kdc2.example.com with kvno 2, encryption type 
ArcFour with HMAC/md5 added to keytab 
Entry for principal host/kdc2.example.com with kvno 2, encryption type 
Triple DES cbc mode with HMAC/sha1 added to keytab 
Entry for principal host/kdc2.example.com with kvno 2, encryption type 
DES cbc mode with CRC-32 added to 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, that is where they are saved. Use the klist -ke command to list the keys in the local keytab file.

4. Kerberos server install

Install the KDC service for the Kerberos slave server:

~# apt-get install krb5-kdc

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

krb5-kdc         1.8.3+dfsg-1                MIT Kerberos key server (KDC)

Following this automated configuration sequence for the package, two familiar problems appear:

Note: xinetd currently is not fully supported by update-inetd.
      Please consult /usr/share/doc/xinetd/README.Debian and itox(8).
krb5kdc: cannot initialize realm EXAMPLE.COM - see log file for details

First, the xinetd super-server is preferred because of its IPv6 compatibility. It is used to run the Kerberos KDC database propagation daemon, which is the default method for copying the master KDC database out to its slaves. To get it running with xinetd, create 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 show if kpropd is running:

~# nmap -sT -p T:754 localhost

Starting Nmap 5.00 ( http://nmap.org ) at 2010-10-10 11:59 CEST
Warning: Hostname localhost resolves to 2 IPs. Using
Interesting ports on localhost (
754/tcp open  krb_prop

Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds
~# _

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 in step 6.

5. Propagation ACL

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


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.

6. Database propagation

The new host, kdc2, does not yet have a KDC database. A new one must be propogated over from the master, kdc1, but first 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 list all of the open TCP and UDP ports used by Kerberos:

~# nmap -sU -sT -p U:88,464,750,T:464,749,754 localhost

Starting Nmap 5.00 ( http://nmap.org ) at 2010-10-10 21:03 CEST
Warning: Hostname localhost resolves to 2 IPs. Using
Interesting ports on localhost (
464/tcp closed        kpasswd5
749/tcp closed        kerberos-adm
754/tcp open          krb_prop
88/udp  open|filtered kerberos-sec
464/udp closed        kpasswd5
750/udp open|filtered kerberos

Nmap done: 1 IP address (1 host up) scanned in 1.30 seconds
~# _

If the result is the same as the services shown above, then the new Kerberos slave KDC is now available! Note that the kpasswd5 and kerberos-adm services are not available on this system (those ports are closed). That is because the Kerberos administration server has not been installed here, so this KDC database is effectively read-only.

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 regularly perform the database dump and propagation tasks that were described in step 6. 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:


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


/usr/sbin/kdb5_util dump /var/lib/krb5kdc/slave_datatrans

if [ $error -ne 0 ]; then

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

for kdc in $slavekdcs; do

	/usr/sbin/kprop $kdc > /dev/null

	if [ $error -ne 0 ]; then

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

exit 0

The main difference 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 in 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-2010. 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: 2017-08-02, 17:50

©2003-2020 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.