When setting up Kerberos, install the server first. If it is necessary
to set up slave servers, the details of setting up relationships between
master and slave servers are covered in the Kerberos 5
Installation Guide located in the
/usr/share/doc/krb5-server-<version-number>
directory (replace <version-number>
with the version number of the krb5-server package
installed on the system).
To configure a basic Kerberos server, follow these steps:
Be sure that clock synchronization and DNS are functioning on
all client and server machines before configuring Kerberos 5. Pay
particular attention to time synchronization between the Kerberos
server and its clients. If the server and client clocks are
different by more than five minutes (this default amount is
configurable in Kerberos 5), Kerberos clients can not authenticate
to the server. This clock synchronization is necessary to prevent an
attacker from using an old Kerberos ticket to masquerade as a valid
user.
It is advisable to set up a Network Time Protocol (NTP)
compatible client/server network even if Kerberos is not being
used. Red Hat Enterprise Linux includes the ntp package for this
purpose. Refer to
/usr/share/doc/ntp-<version-number>/index.htm
for details about how to set up Network Time Protocol servers and https://www.eecis.udel.edu/~ntp
for additional information about NTP.
Install the krb5-libs,
krb5-server, and
krb5-workstation packages on the dedicated
machine which runs the KDC. This machine needs to be very secure
— if possible, it should not run any services other than the
KDC.
If a graphical user interface is required to administrate
Kerberos, install the gnome-kerberos
package. It contains krb5, a GUI tool for
managing tickets.
Edit the /etc/krb5.conf and
/var/kerberos/krb5kdc/kdc.conf configuration
files to reflect the realm name and domain-to-realm mappings. A
simple realm can be constructed by replacing instances of
EXAMPLE.COM and
example.com with the correct domain name
— being certain to keep uppercase and lowercase names in the
correct format — and by changing the KDC from
kerberos.example.com to the name of the
Kerberos server. By convention, all realm names are uppercase and
all DNS hostnames and domain names are lowercase. For full details
about the formats of these configuration files, refer to their
respective man pages.
Create the database using the kdb5_util
utility from a shell prompt:
/usr/kerberos/sbin/kdb5_util create -s
The
create command creates the database that stores keys
for the Kerberos realm. The -s switch forces creation of a
stash file in which the master server key is stored. If
no stash file is present from which to read the key, the Kerberos server
(krb5kdc) prompts the user for the master server password
(which can be used to regenerate the key) every time it starts.
Edit the /var/kerberos/krb5kdc/kadm5.acl
file. This file is used by kadmind to determine
which principals have administrative access to the Kerberos database
and their level of access. Most organizations can get by with a
single line:
Most users are represented in the database by a single principal
(with a NULL, or empty, instance, such as
[email protected]). In this configuration,
users with a second principal with an instance of
admin (for example,
joe/[email protected]) are able to wield full
power over the realm's Kerberos database.
Once kadmind is started on the server, any
user can access its services by running kadmin
on any of the clients or servers in the realm. However, only users
listed in the kadm5.acl file can modify the
database in any way, except for changing their own passwords.
Note
The kadmin utility communicates with the
kadmind server over the network, and uses
Kerberos to handle authentication. For this reason, the first
principal must already exist before connecting to the server over
the network to administer it. Create the first principal with the
kadmin.local command, which is specifically
designed to be used on the same host as the KDC and does not use
Kerberos for authentication.
Type the following kadmin.local command at the
KDC terminal to create the first principal:
Add principals for the users using the
addprinc command with
kadmin. kadmin and
kadmin.local are command line
interfaces to the KDC. As such, many
commands are available after launching the kadmin
program. Refer to the kadmin man page for more
information.
Verify that the KDC is issuing tickets. First, run
kinit to obtain a ticket and store it in a
credential cache file. Next, use klist to view
the list of credentials in the cache and use
kdestroy to destroy the cache and the credentials
it contains.
Note
By default, kinit attempts to authenticate
using the same system login username (not the Kerberos server). If
that username does not correspond to a principal in the Kerberos
database, kinit issues an error message. If
that happens, supply kinit with the name of the
correct principal as an argument on the command line
(kinit
<principal>).
Once these steps are completed, the Kerberos server should be up and
running.