Any Linux system that runs a Kerberos application server requires certain basic preparation, some of which is the same as that for the KDC. In particular, you must set up the /etc/krb5.conf file in much the same way, as described in Section 9.2.1.1. You can, however, omit some sections from this file, namely the [logging] and [kdc] sections.

Before you can run an application server, you must prepare principals for the server (both the server computer and the individual server programs). Furthermore, you must install keytabs for these principals on the application server computer.

The first step in this process is to create the principals. You do this much as you do for ordinary users, with the help of the kadmin or kadmin.local command. To simplify the procedure, pass the -r (in Heimdal) or -randkey (in MIT Kerberos) option. This assigns a random password to the principal. Because the password need only be “known” to software on the server computer, this practice should work well. Generally speaking, you must create principals with the instance name of the computer’s DNS hostname and primary names of host (for the computer as a whole) and named after each server. Some specific servers don’t need their own principals, though. For instance, to enable http://gingko.example.com to function as a Kerberized Telnet server, you can type (using Heimdal’s kadmin) the following:

kadmin> add -r host/gingko.example.com
Max ticket life [1 day]:
Max renewable life [1 week]:
Principal expiration time [never]:
Password expiration time [never]:
Attributes [  ]:
kadmin> add -r telnet/gingko.example.com
Max ticket life [1 day]:
Max renewable life [1 week]:
Principal expiration time [never]:
Password expiration time [never]:
Attributes [  ]:

With the principals created, you must then extract them to a keytab file. You do this with the ext_keytab (Heimdal) or ktadd (MIT Kerberos) command within kadmin:

kadmin> ext_keytab -k gingko.keytab host/gingko.example.com telnet/gingko.example.com

The -k option tells the utility what file to use to store the keytab. If you perform this step from the application server itself, you can give the filename /etc/krb5.keytab directly. If you do this job from another computer, such as the KDC, you can store the keytab under any convenient name, but you must then transfer the file to the application server and store it as /etc/krb5.keytab. Be sure this file is readable only by root (or by the account that will be used to run the server). If you add new Kerberized server programs to an application server, you need to add new principals and repeat this step, specifying principals for all of your server programs. Alternatively, you can combine multiple files using cat or similar tools, adding only the new principals, as needed.

Keytab files function as proof of a server’s identity. For this reason, they’re extremely sensitive. Never transfer them using unencrypted network protocols, such as an unencrypted FTP or NFS server. For network transfers, scp (part of the SSH package) is an acceptable choice. You can also use a floppy disk or other removable media, but when you’re done, be sure to do a low-level reformat of a floppy disk or otherwise securely wipe the keytab file from the disk (say, using wipe); don’t just delete the file with rm. Also, if you use a KDC to generate the keytabs, delete the keytab file from the KDC’s disk, ideally using wipe or another tool that completely destroys the data in a file. The KDC stores a copy in its principals database, and a copy in a disk file might fall into the wrong hands if not given sufficient protection.

Once the application server’s keytab is in place, you can run the server programs. Doing so is much like running non-Kerberos servers. The servers that come standard with Kerberos are typically run from a super server (inetd or xineted). For instance, Example 9-3 shows a file, stored in /etc/xinetd.d, that will launch the Kerberized Telnet server (ktelnetd) that ships with MIT Kerberos.

service telnet
{
   disable      = no
   socket_type  = stream
   protocol     = tcp
   wait         = no
   user         = root
   group        = root
   server       = /usr/sbin/ktelnetd
   server_args  = -a valid
}

The standard Kerberos servers support additional options you must use to enable Kerberos authentication:

These servers support additional options, too, some of which aren’t related to Kerberos operation. Depending on their configuration options, they might or might not accept non-Kerberos logins. If you need more details, consult their manpages or other documentation. (Some packages lack manpages for their servers.)

In addition to these basic servers, Kerberized versions of other servers are available. In some, Kerberos support is part of the main server, although it may be a compile-time option. For instance, Samba supports Kerberos authentication, but only if you provide appropriate compile-time options. (The details of Samba’s Kerberos features are actually rather complex and are beyond the scope of this book.) For some protocols, Kerberos support is available in some servers but not others. Thus, if you want to support Kerberos for particular protocols, you should check the documentation for your preferred servers. If they don’t support Kerberos, try performing a web search. Precisely how you might activate Kerberos support for these tools varies greatly from one server to another, so you’ll have to consult your server’s documentation.