Kerberos was created by MIT as a solution to network security problems. The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection.

Kerberos is both the name of a network authentication protocol and an adjective to describe programs that implement it, such as Kerberos telnet. The current version of the protocol is version 5, described in RFC 1510.

Several free implementations of this protocol are available, covering a wide range of operating systems. The Massachusetts Institute of Technology (MIT), where Kerberos was originally developed, continues to develop their Kerberos package. It is commonly used in the US as a cryptography product, and has historically been affected by US export regulations. The MIT Kerberos is available as the security/krb5 package or port. Heimdal Kerberos is another version 5 implementation, and was explicitly developed outside of the US to avoid export regulations. The Heimdal Kerberos distribution is available as a the security/heimdal package or port, and a minimal installation is included in the base FreeBSD install.

These instructions assume the use of the Heimdal distribution included in FreeBSD.

The Key Distribution Center (KDC) is the centralized authentication service that Kerberos provides. It is the computer that issues Kerberos tickets. The KDC is considered “trusted” by all other computers in the Kerberos realm, and thus has heightened security concerns.

While running the Kerberos server requires very few computing resources, a dedicated machine acting only as a KDC is recommended for security reasons.

To begin setting up a KDC, ensure that /etc/rc.conf contains the correct settings to act as a KDC. As required, adjust paths to reflect the system:

Next, edit /etc/krb5.conf as follows:

This /etc/krb5.conf implies that the KDC will use the fully-qualified hostname kerberos.example.org. Add a CNAME (alias) entry to the zone file to accomplish this if the KDC has a different hostname.

Next, create the Kerberos database which contains the keys of all principals encrypted with a master password. It is not required to remember this password as it will be stored in /var/heimdal/m-key. To create the master key, run kstash(8) and enter a password.

Once the master key has been created, initialize the database using kadmin -l. This option instructs kadmin(8) to modify the local database files directly rather than going through the kadmind(8) network service. This handles the chicken-and-egg problem of trying to connect to the database before it is created. At the kadmin(8) prompt, use init to create the realm's initial database.

Lastly, while still in kadmin(8), create the first principal using add. Stick to the default options for the principal for now, as these can be changed later with modify. Type ? at the kadmin(8) prompt to see the available options.

A sample database creation session is shown below:

Next, start the KDC services. Run service kerberos start and service kadmind start to bring up the services. While there will not be any kerberized daemons running at this point, it is possible to confirm that the KDC is functioning by obtaining and listing a ticket for the principal (user) that was just created from the command-line of the KDC itself:

The ticket can then be revoked when finished:

First, copy /etc/krb5.conf from the KDC to the client computer in a secure fashion, such as scp(1), or physically via removable media.

Next, create /etc/krb5.keytab. This is the major difference between a server providing Kerberos enabled daemons and a workstation: the server must have a keytab. This file contains the server's host key, which allows it and the KDC to verify each others identity. It must be transmitted to the server in a secure fashion, as the security of the server can be broken if the key is made public.

Typically, the keytab is transferred to the server using kadmin(8). This is handy because the host principal, the KDC end of the krb5.keytab, is also created using kadmin(8).

A ticket must already be obtained and this ticket must be allowed to use the kadmin(8) interface in the kadmind.acl. See the section titled “Remote administration” ininfo heimdal for details on designing access control lists. Instead of enabling remote kadmin(8) access, the administrator can securely connect to the KDC via the local console or ssh(1), and perform administration locally using kadmin -l.

After installing /etc/krb5.conf, use add --random-key from the Kerberos server. This adds the server's host principal. Then, use ext to extract the server's host principal to its own keytab. For example:

Note that ext stores the extracted key in /etc/krb5.keytab by default.

If kadmind(8) is not running on the KDC and there is no access to kadmin(8) remotely, add the host principal (host/myserver.EXAMPLE.ORG) directly on the KDC and then extract it to a temporary file to avoid overwriting the /etc/krb5.keytab on the KDC, using something like this:

The keytab can then be securely copied to the server using scp(1) or a removable media. Be sure to specify a non-default keytab name to avoid overwriting the keytab on the KDC.

At this point, the server can communicate with the KDC using krb5.conf and it can prove its own identity with krb5.keytab. It is now ready for the Kerberos services to be enabled. For this example, the telnetd(8) service is enabled in /etc/inetd.conf and inetd(8) has been restarted with service inetd restart:

The critical change is that the -a authentication type is set to user. Refer to telnetd(8) for more details.

Setting up a client computer is easy as only /etc/krb5.conf is needed. Securely copy this file over to the client computer from the KDC.

Test the client by attempting to use kinit(1), klist(1), and kdestroy(1) from the client to obtain, show, and then delete a ticket for the principal created above. Kerberos applications should also be able to connect to Kerberos enabled servers. If that does not work but obtaining a ticket does, the problem is likely with the server and not with the client or the KDC.

When testing a Kerberized application, try using a packet sniffer such as tcpdump(1) to confirm that the password is not sent in the clear.

Various non-core Kerberos client applications are available. The “minimal” installation in FreeBSD installs telnetd(8) as the only Kerberos enabled service.

The Heimdal port installs Kerberos enabled versions of ftpd(8), rshd(8), rcp(1), rlogind(8), and a few other less common programs. The MIT port also contains a full suite of Kerberos client applications.

Users within a realm typically have their Kerberos principal mapped to a local user account. Occasionally, one needs to grant access to a local user account to someone who does not have a matching Kerberos principal. For example, tillman@EXAMPLE.ORG may need access to the local user account webdevelopers. Other principals may also need access to that local account.

The .k5login and .k5users files, placed in a user's home directory, can be used to solve this problem. For example, if .k5login with the following contents is placed in the home directory of webdevelopers, both principals listed will have access to that account without requiring a shared password.:

Refer to ksu(1) for more information about .k5users.

The major difference between MIT and Heimdal relates to kadmin(8) which has a different, but equivalent, set of commands and uses a different protocol. If the KDC is MIT, the Heimdal version of kadmin(8) cannot be used to administer the KDC remotely, and vice versa.

The client applications may also use slightly different command line options to accomplish the same tasks. Following the instructions on the MIT Kerberos web site is recommended. Be careful of path issues: the MIT port installs into /usr/local/ by default, and the “normal” system applications run instead of MIT versions if PATH lists the system directories first.

The following edits should also be made to rc.conf:

This is done because the applications for MIT Kerberos installs binaries in the /usr/local hierarchy.