3.3. Configuring a Kerberos 5 Server
3.3.1. Configuring the Master KDC Server
- 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
/html/index.htmland online at http://www.ntp.org.
- Install the
krb5-workstationpackages 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.
- Edit the
/var/kerberos/krb5kdc/kdc.confconfiguration 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. The man pages of these configuration files have full details about the file formats.
- Create the database using the
/usr/sbin/kdb5_util create -sThe
createcommand creates the database that stores keys for the Kerberos realm. The
-sargument creates 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.aclfile. This file is used by
kadmindto determine which principals have administrative access to the Kerberos database and their level of access. Most organizations can be accommodated by a single line:
*/admin@EXAMPLE.COM *Most users are represented in the database by a single principal (with a NULL, or empty, instance, such as joe@EXAMPLE.COM). In this configuration, users with a second principal with an instance of admin (for example, joe/admin@EXAMPLE.COM) are able to exert full administrative control over the realm's Kerberos database.After
kadmindhas been started on the server, any user can access its services by running
kadminon any of the clients or servers in the realm. However, only users listed in the
kadm5.aclfile can modify the database in any way, except for changing their own passwords.
kadminutility communicates with the
kadmindserver 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.localcommand, which is specifically designed to be used on the same host as the KDC and does not use Kerberos for authentication.
- Create the first principal using
kadmin.localat the KDC terminal:
/usr/sbin/kadmin.local -q "addprinc username/admin"
- Start Kerberos using the following commands:
/sbin/service krb5kdc start /sbin/service kadmin start
- Add principals for the users using the
kadmin.localare command line interfaces to the KDC. As such, many commands — such as
addprinc— are available after launching the
kadminprogram. Refer to the
kadminman page for more information.
- Verify that the KDC is issuing tickets. First, run
kinitto obtain a ticket and store it in a credential cache file. Next, use
klistto view the list of credentials in the cache and use
kdestroyto destroy the cache and the credentials it contains.
kinitattempts 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,
kinitissues an error message. If that happens, supply
kinitwith the name of the correct principal as an argument on the command line:
3.3.2. Setting up Secondary KDCs
kadmind. The master KDC is also the realm's admin server. Additional secondary KDCs keep read-only copies of the database and run
- Copy the master KDC's
kdc.conffiles to the secondary KDC.
kadmin.localfrom a root shell on the master KDC.
- Use the
kadmin.local add_principalcommand to create a new entry for the master KDC's host service.
- Use the
kadmin.local ktaddcommand to set a random key for the service and store the random key in the master's default keytab file.
NoteThis key is used by the
kpropcommand to authenticate to the secondary servers. You will only need to do this once, regardless of how many secondary KDC servers you install.
# kadmin.local -r EXAMPLE.COM Authenticating as principal root/admin@EXAMPLE.COM with password. kadmin: add_principal -randkey host/masterkdc.example.com Principal "host/host/masterkdc.example.com@EXAMPLE.COM" created. kadmin: ktadd host/masterkdc.example.com Entry for principal host/masterkdc.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab. kadmin: quit
kadminfrom a root shell on the secondary KDC.
- Use the
kadmin add_principalcommand to create a new entry for the secondary KDC's host service.
- Use the
kadmin ktaddcommand to set a random key for the service and store the random key in the secondary KDC server's default keytab file. This key is used by the
kpropdservice when authenticating clients.
# kadmin -p jsmith/admin@EXAMPLE.COM -r EXAMPLE.COM Authenticating as principal jsmith/admin@EXAMPLE.COM with password. Password for jsmith/admin@EXAMPLE.COM: kadmin: add_principal -randkey host/slavekdc.example.com Principal "host/slavekdc.example.com@EXAMPLE.COM" created. kadmin: ktadd host/slavekdc.example.com@EXAMPLE.COM Entry for principal host/slavekdc.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab. kadmin: quit
- With its service key, the secondary KDC could authenticate any client which would connect to it. Obviously, not all potential clients should be allowed to provide the
kpropservice with a new realm database. To restrict access, the
kpropservice on the secondary KDC will only accept updates from clients whose principal names are listed in
/var/kerberos/krb5kdc/kpropd.acl.Add the master KDC's host service's name to that file.
# echo host/masterkdc.example.com@EXAMPLE.COM > /var/kerberos/krb5kdc/kpropd.acl
- Once the secondary KDC has obtained a copy of the database, it will also need the master key which was used to encrypt it. If the KDC database's master key is stored in a stash file on the master KDC (typically named
/var/kerberos/krb5kdc/.k5.REALM), either copy it to the secondary KDC using any available secure method, or create a dummy database and identical stash file on the secondary KDC by running
kdb5_util create -sand supplying the same password. The dummy database will be overwritten by the first successful database propagation.
- Ensure that the secondary KDC's firewall allows the master KDC to contact it using TCP on port 754 (krb5_prop), and start the
- Double-check that the
kadminservice is disabled.
- Perform a manual database propagation test by dumping the realm database on the master KDC to the default data file which the
kpropcommand will read (
# /usr/sbin/kdb5_util dump /var/kerberos/krb5kdc/slave_datatrans
- Use the
kpropcommand to transmit its contents to the secondary KDC.
# kprop slavekdc.example.com
kinit, verify that the client system is able to correctly obtain the initial credentials from the KDC. The
/etc/krb5.conffor the client should list only the secondary KDC in its list of KDCs.
- Create a script which dumps the realm database and runs the
kpropcommand to transmit the database to each secondary KDC in turn, and configure the
cronservice to run the script periodically.