||Red Hat Enterprise Linux 6 Essentials eBook now available in PDF and ePub formats for only $9.99
RHEL 6 Essentials contains 40 chapters and over 250 pages.
3.2. Configuring a Kerberos 5 Server
When setting up Kerberos, install the KDC first. If it is necessary to set up slave servers, install the master first.
Ensure that time synchronization and DNS are functioning correctly on all client and server machines before configuring Kerberos.
Pay particular attention to time synchronization between the Kerberos server and its clients. If the time difference between the server and client is greater than the configured limit (five minutes by default), Kerberos clients cannot authenticate to the server. This time synchronization is necessary to prevent an attacker from using an old Kerberos ticket to masquerade as a valid user.
The NTP documentation is located at
and online at https://www.ntp.org
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.
/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 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/sbin/kdb5_util create -s
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.
/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:
*/[email protected] *
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.
kadmind has been 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.
kadmin utility communicates with the
kadmind server over the network, and uses Kerberos to handle authentication. Consequently, 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:
/usr/sbin/kadmin.local -q "addprinc
Start Kerberos using the following commands:
/sbin/service krb5kdc start
/sbin/service kadmin start
Add principals for the users using the
addprinc command within
kadmin.local are command line interfaces to the KDC. As such, many commands — such as
addprinc — 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.
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,
issues an error message. If that happens, supply
with the name of the correct principal as an argument on the command line: