Configuring a Kerberos Application Server

Configuring the KDC is an important step toward using Kerberos, but a KDC by itself isn't very useful. Indeed, it isn't even half of what's needed; you must configure both Kerberos application servers and Kerberos clients to use the KDC. This section covers the first of these topics, and the next ("Configuring a Kerberos Client") covers the second.

NOTE

In some cases, a single computer may function as both a Kerberos application server and a Kerberos client. For instance, this might happen when you use Kerberos as a login authentication protocol. In such cases, you must configure the computer in both ways (as an application server and as a Kerberos client).

Configuring Kerberos

Kerberos on an application server needs some of the same configuration as on a KDC. In particular, the [realms] and [domain_realm] sections of krb5.conf need to be adjusted to reflect your realm configuration, as described earlier. In addition, you need a keytab file for the application server. This file should contain keys for the host itself ( host/ hostname @ REALM. NAME ) and for each Kerberized server you intend to run on the system (for instance, telnet/ hostname @ REALM.NAME if you intend to run a Kerberized Telnet server). You can create a keytab file on the KDC, as described earlier, using the kadmin.local program. Specifically, you use the addprinc command to add principals for the host, then extract the keys for these principals to a keytab file. For instance, you might issue commands like the following:

 kadmin.local:  addprinc \   host/[e-mail]  kadmin.local:  addprinc \   telnet/[e-mail]  kadmin.local:  ktadd -k gingko.keytab host/gingko.threeroomco.com \   telnet/gingko.threeroomco.com  

You should then move the file that results from the final command, gingko.keytab , from the KDC to the application server system, and call that file /etc/krb5.keytab . This file is extremely sensitive, so be sure to move it via a secure method, such as by floppy disk or scp . Once on its destination system, you should delete the original from the KDC and ensure that the file on the application server is readable only by root . Alternatively, you may use kadmin on the application server to create the file locally. Omit the -k gingko.keytab option to the ktadd command, and the system should generate the file in the correct location. This will only work if the KDC's remote administration facilities are correctly configured and running and the application server's basic Kerberos configuration (its realm, for instance) is set correctly.

Running Kerberized Servers

Standard Kerberos packages ship with some Kerberized servers and local authentication tools, such as variants on Telnet, FTP, shell , exec , and login . You can use these servers by replacing their non-Kerberized equivalents with these more secure versions. For instance, if your system uses inetd , you would replace any entries in /etc/inetd.conf for these services with whichever of the following are appropriate:

 klogin  stream  tcp  nowait  root  /usr/kerberos/sbin/klogind \ klogind -k -c eklogin stream  tcp  nowait  root  /usr/kerberos/sbin/klogind \ klogind -k -c -e kshell  stream  tcp  nowait  root  /usr/kerberos/sbin/kshd kshd -k \ -c -A ftp     stream  tcp  nowait  root  /usr/kerberos/sbin/ftpd ftpd -a telnet  stream  tcp  nowait  root  /usr/kerberos/sbin/telnetd \ telnetd -a valid 

Other servers are available in Kerberized forms, as well; the ones included with the Kerberos distribution are just a start. You should consult the documentation for third-party servers to determine precisely what they allow you to do.