Kerberos principal and realm

Kerberized services are configured to authenticate principals who are known to a Kerberos realm. You can think of a realm as a Kerberos database or authentication domain that contains validation data for users, services, and sometimes servers, which are all known as principals.

For example, a realm contains principals’ secret keys, which are the result of a one-way function applied to passwords.

Service principals are generally based on randomly generated secrets rather than passwords.

Here are examples of realm and principal names. Realm names are capitalized by convention to distinguish them from DNS domain names:

Kerberos authentication process

There are several phases to Kerberos authentication. In the first phase, the client obtains credentials to be used to request access to Kerberized services. In the second phase, the client requests authentication for a specific service. In the final phase, the client presents those credentials to the service.

The following illustration summarizes these activities. The service and the client can be the same entity (such as the login window) or two entities (such as a mail client and the mail server).

Kerberos process

  1. The client authenticates to a Kerberos KDC, which interacts with realms to access authentication data.

    This is the only step in which passwords and associated password policy information are checked.

  2. The KDC issues a ticket-granting ticket to the client.

    The ticket is the credential needed when the client wants to use Kerberized services and is good for a configurable period of time, but it can be revoked before expiration. It’s cached on the client until it expires.

  3. The client contacts the KDC with the ticket-granting ticket when it wants to use a Kerberized service.

  4. The KDC issues a ticket for that service.

  5. The client presents the ticket to the service.

  6. The service authenticates the client by verifying that the ticket is valid.

    After authenticating the client, the service determines if the client is authorized to use the service.

Kerberos authenticates clients, but it doesn’t authorize them to use services. For example, many services use a Mac server’s service access control lists (SACLs) to determine whether a client is authorized to use the service.

Kerberos never sends a password or password policy information to a service. After a ticket-granting ticket is obtained, no password information is provided.

Time is very important with Kerberos. If the client and the KDC are out of sync by more than a few minutes, the client fails to achieve authentication with the KDC. The date, time, and time zone information must be correct on the KDC server and clients, and the server and clients should all use the same network time service to keep their clocks in sync.

For more information about Kerberos, see the MIT Kerberos website at web.mit.edu/kerberos/www/index.html.