لطفا منتظر باشید ...
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 ("
the second.NOTE
align=left border=0> 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/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.
