Centralized Authentication with Kerberos 5, Part I

Account administration in a distributed UNIX/Linux environment can become complicated and messy if done by hand. Large sites use special tools to deal with this problem. In this article, I describe how even small installations, such as your three-computer network at home, can take advantage of the same tools.

The problem in a distributed environment is that password and shadow files need to be changed individually on each machine if an account change occurs. Account changes include password changes, addition/removal of accounts, account name changes (UID/GID changes are a big problem in any case), addition/removal of login privileges to computers and so on. I also explain how the Kerberos distribution solves the authentication problem in a distributed computing environment. In Part II, I will describe a solution for the authorization problem.

The problem of authenticating users to a computer is solved mostly through passwords, although other methods, including smart cards and biometrics, are available. These passwords had been stored in /etc/passwd, but now with shadow passwords, they reside in /etc/shadow. Because these files are local to a computer, it is a big problem keeping them up to date. Directory services such as NIS, NIS+ and LDAP were invented to solve this problem. These services, however, introduce a new problem: they work over the network and expose passwords, which are encrypted only weakly.

The authentication protocol implemented by Kerberos combines the advantages of being a networked service and of eliminating the need to communicate passwords between computers altogether. To do so, Kerberos requires you to run two dæmons on a secure server. The Key Distribution Center (KDC) dæmon handles all password verification requests and the generation of Kerberos credentials, called Ticket Granting Tickets (TGTs). A second dæmon, the Kerberos Administration dæmon, allows you to add, delete and modify accounts remotely without logging in to the computer running the Kerberos dæmons. It also handles password change requests from users. With Kerberos, only a password change ever requires transmitting a strongly encrypted password over the network.

The Kerberos KDC grants a temporary credential, a TGT, to the account during the process of authenticating the user. Typically, these credentials have a lifetime of 10 or 24 hours. This lifetime can be configured and should be no longer than 24 hours, in case the TGT is stolen; a thief could use it only for the remaining TGT lifetime. The credential expiration causes no issues if you are using Kerberos only for authentication, as described in this article. However, if you are using Kerberized services, you need to train your users to obtain new credentials after their current ones expire, even though they still are logged in.

Kerberos was invented at MIT. The latest version is Kerberos 5, with its protocol defined in RFC 1510. Today, two Kerberos implementations are freely available (see the on-line Resources). MIT's Kerberos 5 is included in Red Hat Linux, whereas Heimdal is included in SuSE's and Debian's Linux distributions. Kerberos 5 implementations also are included in Microsoft Windows (2000 and later), in Sun's Solaris (SEAM, Solaris 2.6 and above) and Apple's Mac OS X. I use MIT's Kerberos distribution throughout this article because it offers simple password quality checking, password aging and password history out of the box.

You have to meet two prerequisites before you can switch authentication over to Kerberos. First, the clocks on all computers to be included in your Kerberos installation need to be synchronized to the clock of the machine running the KDC. The simplest way of doing this is to use the Network Time Protocol (NTP) on all your machines.

The second requirement is harder to meet. All account names, UIDs and GIDs have to be the same on all your computers. This is necessary because each of these accounts becomes a new and independent Kerberos account, called a principal. You have to go through all your local /etc/passwd files and check whether this requirement is met. If not, you need to consolidate your accounts. If you want to add Windows or Mac OS X clients to your Kerberos installation, you need to look at all the accounts on those machines as well.

If you decide to use the Kerberos package that comes with your Linux distribution, simply install it. If you want to compile the Kerberos distribution yourself, follow the instructions below.

1) Get the source from one of the URLs listed in the on-line Resources. Get the PGP signature of the source package and verify the integrity of the downloaded source with:

% gpg --verify krb5-1.3.4.targz.asc

2) Unpack the source with:

% tar zxvf krb5-1.3.4.tar.gz

3) Change into the source directory:

% cd krb5-1.3.4/src

4) Execute:

% ./configure --help