Section 9.3. Kerberos Application Server Configuration

9.3. Kerberos Application Server Configuration

Setting up a master KDC is the most involved part of configuring a Kerberos realm; however, by itself, a KDC doesn't do much good. The next step in this process is to configure one or more application servers. Each application server computer must have a basic Kerberos configuration, which is similar in some details to the KDC's configuration. You must also create principals for each application server and set up appropriate keytabs. Once this is done, you can run the server programs to make them available.

9.3.1. Setting Up Kerberos

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.

9.3.2. Preparing Application Server Principals

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 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 [  ]:

The Kerberized Telnet server doesn't need its own principal. Thus, you can still run it if you omit the second add command in the preceding example.

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.

9.3.3. Running the Servers

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.

Example 9-3. Sample xinetd configuration for the Kerberized Telnet server

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:

klogind

This program works in conjunction with the rlogin command. You'll ordinarily use the options -k (enable Kerberos authentication), -e (enable encryption), and -c (require a cryptographic checksum from the client, which improves security).

kshd

This remote shell server is used with rsh to enable remote program execution. You'll probably use the same -k, -e, and -c parameters described for klogind.

kftp

This program is a Kerberized FTP server. With some versions of this program, you'll probably use it with the -a valid option, which enables Kerberos authentication. Other versions of the server don't require this option. Consult your package's documentation to learn which option is required.

ktelnetd

This server provides Kerberized Telnet access to a computer. Like kftpd, it may require a -a valid option to enable Kerberos authentication.

These servers support encryption, but only when used with matching Kerberized clients, such as those that ship with Kerberos packages. When used with ordinary non-Kerberized clients, these servers provide no advantages over their non-Kerberized counterparts.

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.)

Some Kerberos packages (notably Heimdal) omit the leading k from the server filenames. In addition, the server files' locations vary depending on the Kerberos package. Check your package's contents to learn the details.

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.