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.
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/gingko.threeroomco.com@THREEROOMCO.COM kadmin.local: addprinc \ telnet/gingko.threeroom.com@THREEROOMCO.COM 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.