LUX 263 - Linux System Administration III

Lesson 8: Chapter 3 in Red Hat Enterprise Linux 6, Using Kerberos

Objectives:

This lesson discusses using Kerberos in a Red Hat network. Objectives important to this lesson:

  1. Kerberos' purpose
  2. Kerberos' methods
  3. Installing a KDC server
  4. Installing a kerberos client
Concepts:
Chapter 3 (?)

The text does not present a chapter on Kerberos, but the Red Hat online documentation site does. Follow this link to find its chapter 3, Using Kerberos.

Most of you should have an idea that Kerberos is an authentication protocol. As the Red Hat text explains, it is typically used at login to perform an encrypted authentication to a server. The first page of the lesson sells the concept several times. It mentions that the standard Linux authentication system does not use encryption, making a less than secure solution. It explains that Kerberos uses a symmetric encryption system, which means that the same key is used by both parties in a transaction, and is provided to them through secure key distribution. The lesson provides a graphic to illustrate the Kerberos process, introducing the term realm, which is defined as the computers managed by a Key Distribution Center (KDC), as well as the master KDC itself and any secondary KDCs. In the image below, the user and computer represent any number of users and computers, and the KDC represents as many KDCs as needed in the realm.

  1. The user sends a request for a TGT, which is a Ticket to Get Tickets. (Sounds stupid, I know, but that is how it starts.) The ID used is called a principal by the KDC.
  2. The KDC checks a database for a match for the supplied principal.
  3. If the principal is in the database, the TGT is created and encrypted with the user's key, which is generated from the user's stored password. The TGT includes a session key, used for encryption of all further transmissions. It is all sent to the requester.
  4. The encrypted message is received, the user supplies his/her password, the user's key is generated by the same process used in the step above, and the ticket is decrypted with that key. The decrypted content enables the requester to actually begin a secure session with the realm, using the session key.

The process above also involves timestamps on each transmission that help ensure that this is not a stolen stream from an earlier legitimate transmission. Services on the network are required to support Kerberos authentication, or some other method that is secure, otherwise security will be lost.

Separate but matching packages must be installed on the servers and clients in the network to enable Kerberos. In the illustration in the text, the admin is installing krb5-server, krb5-workstation, and krb5-libs. Note that an additional package must be installed to allow the use of smart cards. In the rest of the text, the installation assumes this version of Kerberos. Be aware that other version numbers are used by HP and Sun. Be aware, also, that other versions of Kerberos have existed and will exist in the future.

Installing the Master KDC server:

  1. Make sure that DNS and time synchronization are working on the network before installation.
  2. All packages (workstation and server packages) must be installed on the master KDC server.
  3. Edit two sample configuration files on the master KDC server: /etc/krb5.conf and /var/kerberos/krb5kdc/kdc.conf. They must be edited to show the proper names for your realm and domain.
  4. Use kdb5_util create -s to create the KDC database.
  5. Edit the sample configuration file for the KDC daemon (kadmind). It is /var/kerberos/krb5kdc/kadm5.acl. This file must contain the IDs of the staff or group who will administer the KDC.
  6. On the console of the KDC master server issue the command /usr/sbin/kadmin.local -q "addprinc username/admin". Substitute the username of the admin performing this operation.
  7. Start the KDC service with these commands:
    /sbin/service krb5kdc start
    /sbin/service kadmin start
  8. Add principals (as in step 6) for the other admins who are empowered to add more principals.
  9. To verify that tickets are being issued, run kinit to get a ticket and start a credential cache. Use klist to read the list in the cache, then kdestroy to remove the cache.

The text provides procedures for creating secondary KDC servers, which will not be practical in our lab.

Installing the Client:

  1. Make sure that DNS and time synchronization are working on the network before installation.
  2. Only the workstation packages, krb5-libs and krb5-workstation, must be installed on client computers.
  3. Edit the sample configuration file on the client, /etc/krb5.conf, or copy the one from the KDC server to it

The text states that the three steps above are all that you need to do to get a client ready. This is evidently not so, since the instructions continue for another five steps that include generating random keys for each client installed. You may be observing at this time that this is not a quick and easy process, nor is it very automated. Each client added will require editing the database on the server, so you will want to make sure you want to do this before you start.