Cover V10, I12



Implementing Kerberos

David Smith

Kerberos is the mythical three-headed dog guarding the gates of the underworld. It has long been a symbol of unceasing vigilance and was therefore selected as the name of the authentication service for MIT's Project Athena (a collaboration among IBM, DEC, and MIT to develop a ubiquitous networking service for undergraduates at MIT). Project Athena included such innovations as the X Window system, a Directory service named Hesiod, and a messaging service named Zephyr, but only X and Kerberos have become prevalent outside MIT.

Kerberos was designed for an environment with insecure workstations, an insecure network, and moderately secure servers. These assumptions are paralleled in the current Internet, making Kerberos an effective authentication service in modern distributed environments. It is not, however, a complete security service: Kerberos provides for authentication, not authorization or accounting, and is not easily extensible to multi-domain environments. The latter issue is being addressed by current work incorporating PKI support into Kerberos, but at present cross-realm authentication needs to be performed by explicitly extending trust between two Key Distribution Centers (KDC).

Enhancements in Kerberos V allow hierarchical cross-realm trust using transitive trust between different domains. With this architecture, a KDC in realm PLEAIDES.TAURUS.TEST can have a cross-realm trust extended to TAURUS.TEST and will inherit trust to other subdomains of TAURUS.TEST.

In this article, I will demonstrate how to implement Kerberos on multiple operating systems and discuss some of the issues that arise when using "kerberized" applications. I will begin with a discussion of the terminology and roles involved in a Kerberos system, following with the network design for the test domain and the actual implementation steps. For this article, I am using the Kerberos Version 5 distribution obtained from MIT:
This site provides binaries and sources for destinations in the United States and Canada; exportable versions for use by individuals in other countries are available at:

Kerberos is a method to distribute session keys for use in encrypting traffic between two entities in a network. These session keys include a timestamp so that they are valid for a limited duration (preventing replay attacks), and are provided by a Key Distribution Center (KDC). The KDC must be implemented on a secure platform, because it holds the identities of all parties involved in the Kerberos system. The KDC contains two services: an Authentication Service that handles the initial request and a Ticket Granting Service that makes use of an encrypted channel for requests to other services. It should not be used for other services because of the danger that those services might compromise the Kerberos database. If we use the example of one party, Alice attempting to access a service on the system named Bob, the protocol takes the following steps:

1 Alice requests access to the Ticket Granting Server (TGS) from the KDC in plaintext.

2 The KDC sends a session key for the TGS (encrypted in Alice's secret key).

3. Alice uses the session key to get a Ticket Granting Ticket (TGT) from the TGS and subsequently uses that session key and the TGT to obtain tickets for new services. This prevents her from having to continually send traffic encrypted in her secret key (which gives more data to brute-force decoding attack).

4. When Alice requests a service on Bob, she sends a request to the TGS encrypted with her session key that contains her TGT, a newly constructed Authenticator to identify her, and the service identifier for Bob.

5. The TGS returns a ticket valid for use with Bob and also a new session key to use when communicating with Bob, encrypted in the session key for the TGS.

6. Alice sends the Ticket (which includes the specific service requested) and her Authenticator for that ticket to Bob.

7. Bob decrypts the ticket (which is encrypted with Bob's secret key), and extracts the session key for the session with Alice. Bob uses the session key to decrypt the authenticator received from Alice.

The Kerberos protocol ends at this point, with Alice and Bob mutually authenticated (since only the true Bob could decrypt the Ticket), and with a randomly generated session key they can use to encrypt further traffic for the service. Each service needs to have its own session key, although different applications might use the same principals to create their unique session keys.

This protocol design has several implications. First, the KDC must be kept secure and highly available. Kerberos includes the concept of master/slave KDCs so that there is no single point of failure. Each service that uses Kerberos must be "kerberized" so that the initial connection makes use of the TGT to authenticate and provide the session keys to encrypt traffic. Thus, Kerberos cannot be used transparently to a non-kerberized application (such as can be done with SSH). As a growing number of applications are kerberized, however, this issue is becoming less important.

Implementation Steps

Kerberos implementation involves several steps. Before installing the software it is necessary to design the Kerberos realm, the server locations, and ancillary services to keep the KDC functional. Then, the applications to be kerberized must be identified and integrated with the Kerberos system. Finally, the principals must be named and registered in the Kerberos database.

For Kerberos to prevent replay attacks, each ticket and authenticator is timestamped. Therefore, all principals in a Kerberos realm must have a consistent value for the current time. This requires a time service available to all hosts in the realm (and consistent with the time used in other realms). I have used NTP for this purpose and installed NTP clients on all the systems with a local NTP server synchronized with the NTP network.

Realm Design

Kerberos is divided into realms, each a self-contained implementation of a KDC (including an Authentication service and a TGS on the same system) with a set of registered principals. Originally, realm lookup was performed by defining the realm/DNS domain correspondence in a configuration file. But in Kerberos V, it is possible to use new DNS SRV records to locate Kerberos realms and principles using DNS. Kerberos V defaults to looking up KDCs through DNS, but requires explicit configuration to look up realms from DNS names. MIT states that the latter is more prone to spoofing and does not recommend it for sites accessible from the Internet. However, both realm and KDC lookups through DNS were used by Microsoft in their implementation for Windows 2000. Therefore, both will be used in this article to transparently integrate Windows 2000 clients into a Kerberos realm.

Each realm is named with a unique name, by convention an uppercase version of the DNS domain. For example, in the domain taurus.test, the Kerberos realm should be named TAURUS.TEST. If multiple realms are required in an organization, use descriptive names ending with the domain name, such as PLEAIDES.TAURUS.TEST. The names of realms and the KDCs for each realm can be defined in a configuration file on each system, or provided by special DNS records. Although realms are not hierarchical (where a realm named PLEAIDES.TAURUS.TEST would be a subsidiary of the TAURUS.TEST realm), the integration with DNS allows for realm lookups to be made through the DNS hierarchy. Kerberos V also allows transitive trust to be created between subdomains and their parent zones, extending trust to other subdomains of a common parent.

Each client will look for a TXT record in the DNS records for a target host. If there is a record in the host name or in any zone containing that host with the first component of "_kerberos", then the rest of the TXT record is taken as the name of the realm. This allows multiple domains to be managed as a single realm, or separate hosts within a domain to be managed in separate realms.

Each realm then has a DNS style name; and, in the zone records for that domain, special SRV records identify the master and slave KDCs and the Kerberos admin server. These services are defined as follows:

  • _kerberos._udp -- This identifies the Kerberos service on any KDC, both master and slave servers. Only active servers should be included in this list; if the Kerberos daemon is not running, the server name should be removed.
  • _kerberos-master._udp -- This identifies Kerberos service on the master KDC, so that a client can make a final decision on authenticating a user where they may have changed their password but not had enough time for the change to propagate.
  • _kerberos-adm._tcp -- This identifies a server running the kadmind program. Only the master KDC runs this program, which is used to modify the Kerberos database. At present, the kadmin program still needs to look up the admin server using the krb5.conf file, but other applications such as Windows 2000 expect to use the DNS records.
  • _kpasswd._udp -- This identifies the KDC where password changes can be recorded.

MIT recommends that the KDCs be named with aliases that can be used in the krb5.conf files as well. These aliases should be kerberos for the master KDC and kerberos-1, kerberos-2 for all slave KDCs. These aliases are not used in the DNS implementation, which must use the true name of the host in the SRV record. Therefore, while the use of "kerberos" aliases should be continued to support transparent failover for Kerberos IV clients, both the aliases and the canonical names must be registered as principals in the Kerberos realm.

For this project, I configured a realm named TAURUS.TEST with the master KDC named aldebaran.taurus.test, a slave KDC (also supporting SMB) named ain.taurus.test, and several clients in the domain pleaides.taurus.test. Aldebaran is a 100-MHz Pentium running BSD/OS Version 3.0, ain is an 350-MHz Intel Pentium III, while the client systems range from a Motorola StarMax 3000 running Mac OS 9.1 to a 500-MHz Pentium III running Windows 2000.

The DNS zone for taurus.test therefore includes the following records:

$TTL 86400
@    SOA   ain.taurus.test.   root.ain.taurus.test. (
                2001080805 ; serial
                10800      ; refresh
                3600       ; retry
                3600000    ; expire
                86400 )    ; minimum

     NS   ain.taurus.test.

ain  A
kerberos-1 CNAME ain

hyadum    A
alcyone   A
taygeta   A
aldebaran A
kerberos CNAME aldebaran

electra.pleaides A
merope.pleaides     A

_kerberos      TXT  "TAURUS.TEST"
_kerberos._udp      SRV  0 0 88 aldebaran
_kerberos-master._udp    SRV  0 0 88 aldebaran
_kerberos-adm._tcp  SRV  0 0 749 aldebaran
_kpasswd._udp       SRV  0 0 464 aldebaran
Source Configuration and Installation

I downloaded the Kerberos V 1.2.2 source from MIT into /usr/local/src on aldebaran. The source for 1.2.2 comes in one gzipped tar file that unpacks into the krb5-1.2.2 directory tree. This tree includes the doc and src subtrees.

For cross-platform builds, Kerberos supports an object tree so that one source tree can be used by multiple systems. The Kerberos source includes the client utilities required to communicate to the KDC and the libraries needed by kerberized applications. Support for Kerberos IV clients is normally provided (except by Windows 2000) so that older clients can use a Kerberos V server for authentication. Because of the number of different operating systems in this test network, I exported the Kerberos source tree so that executables for each system could be built from a centralized resource.

Most operating systems (including OpenBSD) ship with Kerberos IV, not Kerberos V. Kerberos IV has known buffer overflow vulnerabilities and is no longer supported by MIT. Therefore, I obtained the latest source from MIT. Even with a current version of the operating system, I recommend obtaining the source from MIT to stay up to date with patches and bug fixes. Kerberos requires a working C compiler, GNU make, GNU bison, and, for testing, Perl and Tcl.

Kerberos uses the GNU configure script to tailor the source for each platform. By default, DNS resolution of Kerberos realms is not enabled (because of concern for spoofing), so it will need to be enabled. Also, different operating systems have specific requirements that are identified in the Installation guide (unpacked into the doc directory and available on the MIT site). The default destination prefix is /usr/local, and the default KDC database directory is $PREFIX/var/krb5kdc.

The makefiles include a target for testing the software, so it is important to run "make check" to verify that the code works before installing it. The default tests merely check that the components are built correctly, but support for the DejaGNU test suite is integrated and if present, will test Kerberos client/server interaction. I built Kerberos on BSD/OS with the following commands (when mounted from the appropriate operating system:

% PWD=/usr/local/obj
% /usr/local/src/krb5-1.2.2/src/configure --enable-dns
% make
% make check
% make install
KDC Configuration

Once the software is built and installed, the KDC must be configured. This is done by initializing the database, adding administrators and configuring master and slave KDCs. The configuration files on the KDC servers define the location for the realm databases and the default lifetimes for tickets. The configuration files are text files structured similar to Microsoft .INI files. The kdc.conf file is found on all KDCs in a Kerberos realm (usually located in the Kerberos directory /var/krb5kdc/ and in this implementation contains the following information:

  kdc_ports = 88,750 # this supports the V5 (88) and V4 (750) clients
     database_name = /usr/local/var/krb5kdc/principal
     admin_keytab = /usr/local/var/krb5kdc/kadm5.keytab
     acl_file = /usr/local/var/krb5kdc/kadm5.acl
     dict_file = /usr/local/var/krb5kdc/kadm5.dict
     key_stash_file = /usr/local/var/krb5kdc/.k5.TAURUS.TEST
     kadmind_port = 749
     max_life = 10h 0m 0s
     max_renewable_life = 7d 0h 0m 0s
     master_key_type = des3-hmac-sha1
     supported_enctypes = des3-hmac-sha1:normal \
       des-cbc-crc:normal des-cbc-crc:v4
   kdc_supported_enctypes = des3-hmac-sha1:normal \
       des3-cbc-crc:normal des-\cbc-crc:normal
The krb5.conf file is located in /etc for all Kerberos V systems. Although DNS support has reduced the need for some sections of the krb5.conf file, that file is used to define defaults for Kerberos applications and is therefore a requirement for every host in a Kerberos realm. For most Kerberos hosts it is only necessary to keep the [libdefaults] stanza, adding the [realms] stanza with the admin_server option if access to the Kerberos admin tool is required from that host. For the KDC (master and slave), it contains the following:

    ticket_lifetime = 600
    default_realm = TAURUS.TEST
    default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc
    default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc
       admin_server = kerberos.taurus.test:749

    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmin.log
    default = FILE:/var/log/krb5lib.log
Once these two files are created, the database must be initialized. That is performed with the command kdb5_util:

% /usr/local/sbin/kdb5_util create -r TAURUS.TEST -s
Initializing database '/usr/local/var/krb5kdc/principal' for => \ 
   realm 'TAURUS.TEST', master key name 'K/M@TAURUS.TEST'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: <type the master password>
Re-enter KDC database master key to verify: <again>
This creates the principal database. Because all the credentials are stored in this database, it is imperative to keep the password for this database secure. By default, the files created by this command are kept in /usr/local/var/krb5kdc and include the database itself (principal and principal.ok), the administrative files (principal.kadm5.*), and the stash file (.k5.<<REALM>>). The stash file is used to provide the master password to the Kerberos daemon at system startup. It is not necessary if the startup procedure is designed to prompt for the password at system initialization. Although the password is encrypted and the file is protected, truly paranoid sites may want to not use it at all. It is created with the -s switch to the kdb5_util create command.

The next step is to create an administrator and add it to the ACL file. The ACL file is defined in krb.conf and is named by default "kadm5.acl". The format is:

Kerberos principal  permissions    optional target principal
The only entry required at this time is for an administrator. This file controls access to the Kerberos database so ordinary users do not need to be mentioned in it. Because the file syntax allows wildcard entries, I prepared an initial file allowing all administrators in the realm to have complete access to the database:

*/admin@TAURUS.TEST *
Now we can create the initial administrator on the master KDC using the kadmin.local program. Both kadmin and kadmin.local perform the same functions, but kadmin.local is only available on the master KDC. Kadmin is available on any Kerberos system and allows for remote management. We need to create the first administrator locally so that we can use that principal to create slave servers.

% /usr/local/sbin/kadmin.local
kadmin.local: addprinc admin/admin@TAURUS.TEST
WARNING: no policy specified for "admin/admin@TAURUS.TEST"; \
   defaulting to no policy
Enter password for principal admin/admin@TAURUS.TEST: <password>
Re-enter password for principal admin/admin@TAURUS.TEST: <again>
Principal "admin/admin@TAURUS.TEST" created.
Before exiting from kadmin.local, it is necessary to create the keytab files for the special principals "kadmin/admin" and "kadmin/changepw". This is done with the following commands (a backslash shows where two lines should be typed as one):

kadmin.local: ktadd -k /usr/local/var/krb5kdc/kadm5.keytab \
        kadmin/admin kadmin/changepw
Entry for principal kadmin/admin with kvno 3, encryption type
        Triple DES cbc mode with HMAC/sha1 added to keytab
Entry for principal kadmin/admin with kvno 3, encryption type
        DES cbc mode with CRC-32 added to keytab
Entry for principal kadmin/changepw with kvno 3, encryption type
        Triple DES cbc mode with HMAC/sha1 added to keytab
Entry for principal kadmin/changepw with kvno 3, encryption type
        DES cbc mode with CRC-32 added to keytab
Now, the KDC and Kerberos admin server can be started:

% /usr/local/sbin/krb5kdc
% /usr/local/sbin/kadmind
Each program will run as a daemon. These commands should be added to the appropriate startup file for the system (/etc/init.d/krb5 for Red Hat, /etc/rc.local for BSD systems). Starting automatically will require a stash file. After starting, the log files should be checked to verify that they started correctly. The file krb5kdc.log showed "commencing operation" as the last line, while the file kadmind.log showed "starting".

Adding Slave Servers

The slave servers now need to be configured. Assuming that the Kerberos software has been compiled and installed on the slave server, the slaves must be created as Kerberos principals. They must also have their keytabs extracted, installed locally, and configured for database propagation.

Each host in a Kerberos system needs to be defined as a principal in the Kerberos database and have its secret key extracted to a keytab file stored locally. The keytab file holds an encrypted copy of the host's password, but it must be protected from unauthorized access by making it unreadable by anyone but root and excluded from all backups. Both the canonical name and the Kerberos alias must be added as principals for the master and slave servers, and keytabs for both names must be stored locally. Additionally, the host's idea of its own name must match the principal name as a fully qualified domain name. On Linux systems, this is done making FQDN the first entry in the /etc/hosts file (where the hostname is picked up). Other operating systems will have different techniques.

On aldebaran.taurus.test (Kerberos), run the following as root:

% /usr/local/sbin/kadmin -p admin/admin
Password: <enter admin password>
kadmin: addprinc -randkey host/aldebaran.taurus.test
WARNING: no policy specified for "host/aldebaran.taurus.test@TAURUS.TEST"; \
   defaulting to no policy.
kadmin: ktadd host/aldebaran.taurus.test
kadmin: Entry for principal host/aldebaran.taurus.test@TAURUS.TEST with kvno
3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:
kadmin: Entry for principal host/aldebaran.taurus.test@TAURUS.TEST with kvno
3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:
kadmin: addprinc -randkey host/kerberos.taurus.test
WARNING: no policy specified for "host/kerberos.taurus.test@TAURUS.TEST"; \
   defaulting to no policy.
kadmin: ktadd host/kerberos.taurus.test
kadmin: Entry for principal host/kerberos.taurus.test@TAURUS.TEST with kvno
3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:
kadmin: Entry for principal host/kerberos.taurus.test@TAURUS.TEST with kvno
3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:
Do the same on the slave server, ain.taurus.test (kerberos-1):

% /usr/local/sbin/kadmin -p admin/admin
Password: <enter admin password>
kadmin: addprinc -randkey host/ain.taurus.test
WARNING: no policy specified for "host/ain.taurus.test@TAURUS.TEST"; \
   defaulting to no policy.
kadmin: ktadd host/ain.taurus.test
kadmin: Entry for principal host/ain.taurus.test@TAURUS.TEST with kvno 3, \
   encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE: /etc/krb5.keytab.
kadmin: Entry for principal host/ain.taurus.test@TAURUS.TEST with kvno 3, \
   encryption type DES cbc mode with CRC-32 added to keytab WRFILE: /etc/krb5.keytab.
kadmin: addprinc -randkey host/kerberos-1.taurus.test
WARNING: no policy specified for "host/kerberos-1.taurus.test@TAURUS.TEST"; \
   defaulting to no policy.
kadmin: ktadd host/kerberos-1.taurus.test
kadmin: Entry for principal host/kerberos-1.taurus.test@TAURUS.TEST with \
   kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to \
   keytab WRFILE: /etc/krb5.keytab.
kadmin: Entry for principal host/kerberos-1.taurus.test@TAURUS.TEST with \
   kvno 3, encryption type DES cbc mode with CRC-32 added to keytab \
   WRFILE: /etc/krb5.keytab.
Now we can enable propagation of the database from the master to the slave KDCs. This process will eventually need to be performed as a cron job, but the initial stage will perform it manually. First, each KDC needs an acl file for propagation (by default named /usr/local/var/krb5kdc/kpropd.acl, containing the principals for each of the KDCs:

The propagation daemon needs to be added to /etc/inetd.conf as follows:

krb5_prop stream tcp nowait root /usr/local/sbin/kpropd kpropd
eklogin     stream tcp nowait root /usr/local/sbin/klogind \
     klogind -k -c -e
The following services must also be defined in the /etc/services file:

kerberos       88/udp
kerberos       88/tcp
krb5_prop     754/tcp
kerberos-adm  749/tcp
kerberos-adm  749/udp
eklogin      2105/tcp
The dump propagation is done on the master KDC with the following commands:

% /usr/local/sbin/kdb5_util dump /usr/local/var/krb5kdc/slave_datatrans
% /usr/local/sbin/kprop -f/usr/local/var/krb5kdc/ \
   slave_datatrans kerberos-1.taurus.test
If successful, the kprop command will print "Database propagation to kerberos-1.taurus.test: SUCCEEDED", and the slave will have a current copy of the /usr/local/var/krb5kdc/principal databases. Some common causes for failure are the inclusion of hosts in the _kerberos._udp SRV records that are not running the krb5kdc program, or a hostname on the slave that is not listed in the known Kerberos principals. The Kerberos distribution includes a shell script, krb5-1.2.2/src/slave/kslave_update, that can be started as a cron job to automatically propagate the database to a named slave KDCs.

It is now possible to create a stash file for the slave KDC and to start the krb5kdc daemon. The kadmind daemon is only started on the master server.

% /usr/local/sbin/kdb5_util stash
kdb5_util: Cannot read/find stored master key while reading master key
kdb5_util: Warning: proceeding without master key
Enter KDC database master key: <Enter database password>
Once the Kerberos daemon is restarted, the slave server can be added to the _kerberos._udp SRV record in the DNS, and the DNS can be restarted.

Adding Principals

A Kerberos principal is a person or host known to the Kerberos system. A principal's name is typically divided into three parts: PRIMARY/INSTANCE@REALM, although the instance portion is optional. For example, a host would use the format host/hostname.domain@REALM (although the REALM can be implied), while an individual would typically leave off the instance, simply using person@REALM. Microsoft, however, does not support this structure and requires a different format for cross-platform integration.

In Kerberos, only hosts that supply services need to be registered as principals. Since services include telnet, ftp, and the Berkeley r* commands (as well as ssh). In practice, most UNIX hosts will need to be registered. However, Windows and Macintosh hosts do not need to be registered unless they are providing file services. As described above, a host is typically registered by running the kadmin program on it, creating the principal and exporting its host key to the local keytab file. In this process, we rely on Kerberos to generate a random key for the host password:

myhost % /usr/local/sbin/kadmin -p admin/admin
Password: <enter admin password>
kadmin: addprinc -randkey host/myhost.taurus.test
WARNING: no policy specified for "host/myhost.taurus.test@TAURUS.TEST";
defaulting to no policy.
kadmin: ktadd host/myhost.taurus.test
kadmin: Entry for principal host/myhost.taurus.test@TAURUS.TEST with kvno 3,
encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:
kadmin: Entry for principal host/myhost.taurus.test@TAURUS.TEST with kvno 3,
encryption type DES cbc mode with CRC-32 added to keytab WRFILE:
kadmin: exit
myhost %
Windows 2000 servers do not support the ktadd command, so they are created differently. According to Microsoft, the process for integrating a Windows 2000 workstation in an existing Kerberos realm requires the following steps:

1. Add the Windows 2000 workstation as a principal in the realm.

2. Identify the realm and KDC to the workstation.

3. Map the usernames to principals in the realm for single sign-on.

The first step is performed in the Kerberos realm using kadmin:

% kadmin
kadmin: ank -pw <password> host/merope.pleaides.taurus.test
WARNING: no policy specified for \
   host/merope.pleaides.taurus.test@TAURUS.TEST; \
   defaulting to no policy
Principal "host/merope.pleaides.taurus.test@TAURUS.TEST" created
The next two steps are performed on the Windows 2000 workstation. Microsoft supplies the commands ksetup and ktpass for this purpose. Although they are not installed by default, they can be added from the Windows 2000 distribution media by running SETUP from the \support\tools\ directory on the CD. The tools are placed in the directory \Program Files\Support Tools\, which is added to the path after rebooting.

C:> ksetup /setdomain TAURUS.TEST
C:> ksetup /addkdc TAURUS.TEST kerberos.taurus.test
C:> ksetup /setmachpassword <password> #use the same one as above
It is now necessary to restart the Windows 2000 workstation. After it reboots, the command to map users can be issued and Windows will use the Kerberos V KDC for authentication. Multiple maps can be provided, including wildcards. In this example, we map the Kerberos admin user to Administrator and all others to corresponding local users. Note that the use of instances in a principal name for users is not supported by Windows (the slash is interpreted as an NT domain).

C:> ksetup /mapuser admin@TAURUS.TEST Administrator
C:> ksetup /mapuser * *
Microsoft does not have a kadmin client and, therefore, does not provide an encrypted channel over which to transmit host keys. Thus, it is necessary to explicitly specify the machine password when adding it to the Kerberos V database.


Each user in a Kerberos system must be defined as a principal. Most individual users would be created without an instance, but it is useful to include instances where a user performs multiple roles. For example, an individual might have a principal record of joe@taurus.test, but also have a principal for administrative use stored as joe/admin@taurus.test. This latter record would match the administrative ACL file, kadmin.acl, as defined above that allowed all "*/" users full administrative access to the system.

Kerberized Applications

Kerberos would not be much use without a way to integrate it into applications. The standard distribution includes the following applications, which would replace the non-kerberized versions in /etc/inetd.conf on Kerberos hosts:

These programs are in /usr/local/sbin, and the corresponding client applications are in /usr/local/bin. Those directories should be placed ahead of the /usr/bin and /usr/sbin directories in standard PATH variables. Besides these applications, Kerberos clients also include the following programs:

  • login.krb5 -- A login program to allow single sign-on.
  • kinit -- Obtains tickets for you.
  • klist -- Lists currently held tickets.
  • kdestroy -- Destroys your tickets (should be run automatically on logout).
  • kpasswd -- Changes your password on the KDC.
  • ksu -- Changes your default principal (like su but referring to the KDC).

Kerberos IV Integration

Since many platforms have Kerberos IV clients and it may be impossible to upgrade them to Kerberos V, I will show how to configure a Kerberos IV client to communicate with the Kerberos V server. The client configuration files are stored in /etc/kerberosIV and named krb.conf and krb.realms. They must have entries that define the default realm and identify the KDCs for that realm. Krb.conf should define the local realm in the first line and follow that by any number of lines defining realm/host entries. In TAURUS.TEST, a Kerberos IV krb.conf file will look like this:

TAURUS.TEST   kerberos.taurus.test server admin
TAURUS.TEST   kerberos-1.taurus.test server
The krb.realms file provides a way to translate from a host name to a realm name without implicitly matching them to the DNS domain. It contains lines of the form:

host_name    kerberos_realm
domain_name  kerberos_realm
where a domain name is identified by an initial dot (.) before the domain. A krb.realm file for TAURUS.TEST would therefore be:

taurus.test  TAURUS.TEST
.taurus.test TAURUS.TEST
This will cover both the domain name and any hosts listed within that domain. With this configuration, a user can run the Kerberos IV client packages available under operating systems such as OpenBSD. To run kerberized services it is still necessary to upgrade to Kerberos V.

Server Management

Because the KDC is a critical component of a Kerberos system, it must be closely protected. MIT recommends that /etc/inetd.conf be limited to the following services to control access to the KDC:

time   stream tcp nowait root internal
time   dgram    udp nowait root internal
krb5_prop stream tcp nowait root /usr/local/sbin/kpropd kpropd
eklogin     stream tcp nowait root /usr/local/sbin/klogind \
     klogind -k -c -e
The eklogin service requires an encrypted session and will reject a non-encrypted rlogin attempt. To connect to the KDC, it is necessary to issue the following commands:

% kinit
Password for dsmith@TAURUS.TEST: <enter password>
% rlogin -x aldebaran.taurus.test
Kerberos Resources

MIT has an extensive Kerberos Web site at:
The FAQ from that site provides additional information including some information about connections to Windows 2000. Microsoft also has an extensive set of pages on Kerberos under Windows 2000, including step-by-step instructions for interoperability:
They do not provide any information about configuring NT 4.0 clients to support Kerberos.

Cygnus developed a Kerberos implementation (based in Kerberos IV) for Windows NT that integrated the login screen to a KDC, but it required the Cygwin libraries and is no longer available from Cygnus. It has been mirrored in several locations and can now be obtained from the site The Kerberos protocol is defined in RFC 1510.

David Smith has been programming for more than 30 years and has worked as a consultant for the last 10. He has designed access control systems and data transfer protocols for several applications on multiple platforms. He is currently an independent consultant and can be contacted at: