Kerberos: The Definitive Guide

Services and Keytabs

Remember that Kerberos provides a service that verifies the identity of two connection endpoints, identified by unique names, or principals. It is rather obvious so far that each user is associated with a principal name that is stored in the Kerberos database, since all authentication schemes by their very nature require that all users be uniquely identified with an associated secret. However, the concept that all services that users contact through Kerberos also require a principal and secret key is a new one to most administrators.

On Windows hosts, service keys are automatically created as needed when Kerberized services are installed. Unix-based Kerberos realms require a bit more manual configuration, and this section discusses the issues that Kerberos administrators have to work with when installing Kerberized services.

As we saw in Chapter 2, a service principal has three major components: the service name, the hostname of the machine that provides the service, and the Kerberos realm to which the machine belongs. Here’s a sample service principal:

imap/[e-mail]

In this example, the service name is “imap”, the host that this service is running on is “freebsd.wedgie.org”, and the realm that this machine belongs to is “WEDGIE.ORG”.

Of course, a secret key is associated with every principal, and so there is an encryption key or keys (possibly more than one, with different key version numbers, encryption types, and salts) associated with a given ...