/etc/rc.d/init.d/krb5server initscript

So how do you secure your network and each workstation or server with one tool? The answer is simple: Kerberos. Kerberos is a program that authenticates workstations against a server, and Vincent Danen will explain it all to you.

So how do you secure your network and each workstation or server with one tool? The answer is simple: Kerberos. Kerberos is a program that authenticates workstations against a server. It was developed at MIT and is named after the three-headed watchdog from Greek mythology. This watchdog guarded the entrance to Hades, or the underworld, and was a fearsome beast indeed. Kerberos is aptly named. In this Daily Drill Down, I’ll show you how to install and configure Kerberos to secure your network.

Using Kerberos, a client (generally a user or host) sends a request for a ticket to the Kerberos server, or Key Distribution Center (KDC). The KDC creates a Ticket-Granting Ticket (TGT) for the client and encrypts it using the client's password as the key. It then sends the encrypted ticket back to the client. At this point, the client attempts to decrypt the TGT using its password. If the client successfully decrypts the TGT (which means it provided the correct password), it keeps the decrypted TGT as proof of its identity.

TGTs are not indefinite; they expire at a specified time. Having the TGT, however, allows the client to obtain additional tickets, which grant permission to access specific services. These additional tickets are transparent to the users and require no additional work on their part.

Kerberos negotiates the communication between any two points on the Internet or an intranet. It can also encrypt the communication between two points. Because of this, it provides a layer of security that is independent of either side of any firewall.

Sounds a little daunting, doesn't it? Well, it isn't. Kerberos was designed to be easy to use. Most of the commands it provides are nearly identical to the Linux network programs you already use. It is a single-sign-on system, which means that you only need to type your password once per session. Everything else is transparent. After you have entered your password, Kerberos handles all of the authentication and encryption itself.

Other tools—and why they fail
Everyone knows how vital it is to secure your computer. Numerous tools exist to help enforce system security. Many people are familiar with tools like PGP (Pretty Good Privacy) and GPG (GNU Privacy Guard) for encrypting messages and files, and SSH (Secure Shell) and OpenSSH for secure logins to remote servers and secure copying of files. Other security implementations, such as SSL (Secure Socket Layer), exist to provide security during Web browsing. Yet another security tool is a firewall on a computer, specifically under Linux using ipfwadm in the 2.0.x kernels and ipchains in the 2.2.x kernels.

All of these security tools are essential to keeping your system and information secure from unwanted outside interference. Using SSH to remotely log in to computers provides a secure encryption layer to keep passwords private. PGP and GPG provide both encryption to keep your data and e-mail messages private and other means to authenticate e-mail so that people know you wrote it—and not someone pretending to be you. SSL provides a secure encryption layer between the Web client (browser) and Web server, the FTP client and FTP server, or even the e-mail client and POP3/IMAP servers.

There is one downfall to all of these security tools, however. Firewalls are meant to keep people out of your system—and perhaps to keep people using your system from reaching certain sites and services. SSL and SSH are exceptionally good tools for dealing with remote servers where you do not want vital data transmitted in clear text, but they only deal with remote machines and provide no means of authenticating local users. Many studies have shown that most system compromises come from within firewalls. Someone who already has internal access to your system can compromise your network. Many companies are not prepared for this kind of intrusion because they assume that employees know where they belong and where they do not and that they know better than to snoop around. Unfortunately, this is not always the case.

Installing Kerberos
Kerberos is available for operating systems other than Linux. It can be used on any UNIX system, and it is also available for Macintosh and MS Windows systems. Currently, only Canadian or U.S. citizens can download Kerberos. MIT is exploring the possibility of making Kerberos available worldwide but, due to U.S. export laws, they are currently playing it safe and making it available only to people in North America.

You can download Kerberos at the Kerberos Web site. You can download the Windows version of Kerberos here as well, or you can use a special Windows version called MinK (Minimum Kerberos), also from MIT.

The current version as of this writing is Kerberos5 version 1.2.1. This is the version you should be downloading for Linux. If you use Red Hat Linux, you will have Kerberos with your distribution. Red Hat Linux 7.0 ships with Kerberos5 1.1.1, and Red Hat has recently released Kerberos5 1.1.1 for Red Hat 6.x.

If you are using Red Hat, I strongly recommend installing the RPMs supplied. The RPMs you’ll need to install for the Kerberos clients are:
  • krb5_configs
  • krb5_libs
  • krb5_workstation

If you are installing a Kerberos server, you will also need to install the krb5_server RPM.

For the purpose of this Daily Drill Down, however, we will install Kerberos by source. Download the krb5_1.2.1.tar file and save it to /usr/local/src/kerberos. Now unpack the archive using this command:
tar xvf krb5_1.2.1.tar

You will now have six files in your directory. They are krb5_1.2.1.crypto.tar.gz,krb5_1.2.1.doc.tar.gz, krb5_1.2.1.src.tar.gz, and the corresponding PGP signatures for each gzipped archive. Unpack each of these archives using these commands:
mkdir DIST
tar xvzf ../krb5_1.2.1.crypto.tar.gz
tar xvzf ../krb5_1.2.1.doc.tar.gz
tar xvzf ../krb5_1.2.1.src.tar.gz

You will now have a directory called DIST/krb5_1.2.1/, which contains the contents of these three archives. The crypto archive contains all of the crypto library sources, while the src archive contains all of the Kerberos sources. The doc archive contains the documentation for Kerberos.

Next we want to configure and install Kerberos. Kerberos uses autoconf, which makes configuring and compiling Kerberos much simpler. Follow these instructions:
cd krb5_1.2.1/src
./configure --prefix=/usr/kerberos --withnetlib=-lresolv --
localstatedir=/var/kerberos  --with-krb4

This tells configure to build Kerberos and place everything in the /usr/kerbneros directory. We want to keep Kerberos separate from everything else on the system because of the similar programs it installs. We also choose to use the resolv library to perform hostname resolving. Finally, we include backward compatibility for Kerberos4. The configure script will run for a few moments, creating the various Makefiles and ensuring that you have the proper libraries and utilities installed on your system to compile it.

Once configure is complete, we run the almighty make command and grab a cup or two of coffee:

When Kerberos has finished building everything, we want to test our build to ensure that it built properly. You accomplish this by running these commands:
make check

The first command switches you to the user root. You will need root access to perform all the tests. You can still run make check as a regular user, but you will be unable to perform all the tests. If any glaring errors come up, you’ll need to go through the steps again. If all goes well, you’ll need to install the program as root. As root, run the following command:
make install

This will install everything into the /usr/kerberos directory tree. There you will find everything you need for Kerberos: a bin directory, the include files, the libraries, the man pages, the sbin directory, and a share directory for information Kerberos uses. You could easily install all this into your /usr directory tree, but Kerberos includes programs such as ftp, rcp, rlogin, rsh, and telnet in the bin directory, and you do not want these to overwrite existing files on your system.

Configuring Kerberos
Now that you have Kerberos installed on one or more machines, it’s time to configure it. We’ll assume you’re using Kerberos within your own network and that you have installed it on two computers, following the installation steps above.

The first step is to install the KDC, or Key Distribution Center, which will issue Kerberos tickets. You can optionally have more than one KDC, each containing a copy of the Kerberos database. The master KDC, however, holds the master copy of the database, which is then propagated to the slave KDCs at regular intervals. All changes to the database must be made on the master KDC, as the master is the only KDC that allows database administration. The slave KDCs can provide ticket-granting services, which allow clients to obtain tickets when and if the master KDC is unavailable. You only need to set up slave KDCs if you want a little more redundancy on your network, and they really are useful only on larger networks. If you want more information on configuring slave KDCs, read the Kerberos installation documentation. Most people with smaller networks (for example, fewer than 10 computers) will probably want to avoid setting up slave KDCs as they are somewhat troublesome. In this Daily Drill Down, we will not be looking at slave KDCs, so everything we will discuss will assume a single-KDC (master-only) scenario.

Select which computer you want to be your master KDC and approach it. You need to edit the configuration files on the master, specifically the two configuration files /etc/krb5.conf and /var/kerberos/krb5kdc/kdc.conf. You will want an /etc/krb5.conf file that looks similar to this:
default = FILE:/var/log/krb5lib.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

ticket_lifetime = 24000
default_realm = EXAMPLE.COM
default_tkt_enctypes = des3_hmac_sha1 des_cbc_crc
default_tgs_enctypes = des3_hmac_sha1 des_cbc_crc
kdc =
admin_server =
default_domain =

[domain_realm] = EXAMPLE.COM = EXAMPLE.COM

This code sets up a few basic rules for your Kerberos realm. The [libdefaults] section deals with defaults on ticket generation. This indicates that tickets have a lifetime of 24,000 seconds, or 400 minutes. It indicates the default realm, which in this case is EXAMPLE.COM (realms are always specified in uppercase letters; you can think of a realm as your domain name within Kerberos). Then it specifies some ticket-encryption types.

The [realms] section defines your realm. Here we define the realm EXAMPLE.COM and list our KDCs (in this case, We also define the master (admin) server, which is also We specify the default domain, which is The next section, [domain_realm], merely specifies that all systems matching the domain belong to the EXAMPLE.COM realm.

You’ll need to create the next configuration file, /var/kerberos/krb5kdc/kdc.conf, as well, but you’ll most likely need to create the directory first. Create the file with the following contents:
kdc_ports = 88,750
dict_file = /usr/dict/words

master_key_type = des3_hmac_sha1
supported_enctypes = des3_hmac_sha1:normal des_cbc_crc:normal
database_name = /var/kerberos/krb5kdc/principal
acl_file = /var/kerberos/krb5kdc/kadm5.acl
admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
key_stash_file = /var/kerberos/krb5kdc/.k5.EXAMPLE.COM
kadmind_port = 749


The [kdcdefaults] section specifies the defaults for the KDC. The [realms] section specifies some more detailed information about the realm we defined previously, EXAMPLE.COM. We specify where to keep the database, the ACL (Access Control List), and the keytab (more on this later), as well as some other options.

For more information on both configuration files, you can view the man pages in /usr/kerberos/man/man5 by using these commands:
cd /usr/kerberos/man/man5
man ./kdc.conf.5
man ./krb5.conf.5

Now you need to create the Kerberos database on the master KDC. We’ll use the kdb5_util command on the master KDC to create the database and a stash file. The stash file is a local copy of the master key that resides in encrypted form on the KDC's hard drive. The stash file is used to authenticate the KDC to itself automatically before starting the Kerberos daemons. The stash file is a very important file and can be a potential security hole if not secured correctly. This file should exist only on a local hard drive and should be readable only by root and writeable by no one. Also, this file should not be a part of any backup routine unless the backups are physically secured as well.

Change to the /usr/kerberos/sbin directory. This is where kdb5_util is located. Run the program like this:
cd /usr/kerberos/sbin
./kdb5_util create _r EXAMPLE.COM _s

You will now be asked to enter the KDC database master key. This key can be any string and should be as difficult to guess as possible (like any other good password). Once you have completed this task, you will have five new files in your /var/kerberos/krb5kdc directory, which you specified in your kdc.conf file. These files are .k5.EXAMPLE.COM, principal, principal.kadm5, principal.kadm5.lock, and principal.ok. If you do not want the stash file created (.k5.EXAMPLE.COM), run kdb5_util without the _s command switch and remove the key_stash_file keyword from your kdc.conf file. If you do this, however, you will be required to enter the database master key (password) every time you start the Kerberos daemons.

The Access Control List
The next step is to create an Access Control List (ACL) and put the Kerberos principal of at least one of the administrators into it. The file we are going to create is /var/kerberos/krb5kdc/kadm5.acl, which is specified as such in our kdc.conf file. The syntax for the acl file is shown here:
Kerberos principal permissions optional_target_principal

Kerberos principals (which include the principal and optional target principal) can contain the * wildcard, so you can have an administrator with full permissions. Insert the following into your kadm5.acl file:
*/admin@EXAMPLE.COM  *

To give another quick example, suppose you wanted a principal called fred@EXAMPLE.COM to be able to add, list, and inquire about any principals with the instance root. You would add the following to your kadm5.acl file:
fred@EXAMPLE.COM   ali    */root@EXAMPLE.COM

There are a number of different acl files you can define, which I’ll discuss in further detail in the second Daily Drill Down of this series. It should be enough for this installation that you use the principal admin@EXAMPLE.COM for your configuration with all ACLs (denoted by the * character). We'll examine the nitty gritty a little later on.

The next step is to add an administrative principal to the Kerberos database. This also must be done on the master KDC. The administrative principal you add should be the one listed in the kadm5.acl file above, which in this case is admin@EXAMPLE.COM. To do this, you’ll need to use the kadmin.local program in the /usr/kerberos/sbin directory, like this:
cd /usr/kerberos/sbin

You will be given the following prompt:
Authenticating as principal root/admin@EXAMPLE.COM with password.

At this prompt, type the following:
addprinc admin/admin@EXAMPLE.COM

You will then be asked for a password for this principal. After entering it twice, you will again be at a kadmin.local: prompt. Type exit to leave. You have now entered your administrative principal into the database.

We must now create the keytab for kadmind. This is the key that kadmind will use to decrypt the administrator's Kerberos tickets to determine whether access will be granted to the database. You need to create the kadmind keytab with entries for the principals kadmin/admin and kadmin/changepw, as these principals are placed into the database automatically when you create it. Once again, we must run the kadmin.local program, but using a different command. When you reach the kadmin.local prompt, enter the following command:
ktadd _k /var/kerberos/krb5kdc/kadm5.keytab kadmin/admin kadmin/changepw

Once the command has completed, type exit to quit. The _k parameter specifies the keytab file to write to, and it must be the same as that specified in your kdc.conf file.

At this point, you’re ready to start the Kerberos daemons on the master KDC. To start Kerberos on the master KDC, type the following two commands:

The daemons will fork into the background and free up your console. You can begin these daemons automatically by adding them into your /etc/rc.d/rc.local file; however, to do so, you must have created a stash file. RPM users can use the /etc/rc.d/init.d/krb5server initscript found in the Red Hat RPMs. For those who use initscripts but are not installing the RPMs, you can still use the script, of which a modified copy is found here.
# kbrbserver.init          Start and stop the Kerberos 5 servers.
# chkconfig: 345 35 65
# description: Kerberos 5 is a trusted third-party authentication system. \
#This script starts and stops the servers that Kerberos IV and 5 \
#clients need to connect to.
# processname: krb5kdc
# processname: kadmind

# Get config.
. /etc/sysconfig/network

# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0

# Source function library.
. /etc/rc.d/init.d/functions

# Shell functions to cut down on useless shell instances.
start() {
if [ ! _f /var/kerberos/krb5kdc/principal ] ; then
exit 0
action "Starting Kerberos 5 KDC" /usr/kerberos/sbin/krb5kdc
action "Starting Kerberos 5 Admin Server" /usr/kerberos/sbin/kadmind
touch /var/lock/subsys/krb5server
stop() {   echo _n "Stopping Kerberos 5 Admin Server" && killproc kadmind
echo _n "Stopping Kerberos 5 KDC" && killproc krb5kdc
rm _f /var/lock/subsys/krb5server

# See how we were called.

case "$1" in
status krb5kdc
status kadmind
if [ _f /var/lock/subsys/krb5server ] ; then
echo "Usage: krb5server {start|stop|status|restart|condrestart}"
exit 1

exit 0
There are a number of steps required to make Kerberos function properly, but it is well worth your time. At this point, we have installed Kerberos on two computers and have completely set up and started the KDC master server. In the second Daily Drill Down of this series, we will take a closer look at what Kerberos principals are, what ACLs exist, and how to make use of Kerberos with your network.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.


Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.


Editor's Picks