How the Kerberos Service Works
The following is an overview of the Kerberos authentication system. For a more detailed description, see How the Kerberos Authentication System Works.
From the user's standpoint, the Kerberos service is mostly invisible after the Kerberos session has been started. Commands such as rsh or ftp work about the same. Initializing a Kerberos session often involves no more than logging in and providing a Kerberos password.
The Kerberos system revolves around the concept of a ticket. A ticket is a set of electronic information that identifies a user or a service such as the NFS service. Just as your driver's license identifies you and indicates what driving privileges you have, so a ticket identifies you and your network access privileges. When you perform a Kerberos-based transaction (for example, if you remote log in to another machine), you transparently send a request for a ticket to a Key Distribution Center, or KDC. The KDC accesses a database to authenticate your identity and returns a ticket that grants you permission to access the other machine. “Transparently” means that you do not need to explicitly request a ticket. The request happens as part of the rlogin command. Because only an authenticated client can get a ticket for a specific service, another client cannot use rlogin under an assumed identity.
Tickets have certain attributes associated with them. For example, a ticket can be forwardable, which means that it can be used on another machine without a new authentication process. A ticket can also be postdated, which means that it is not valid until a specified time. How tickets can be used, for example, to specify which users are allowed to obtain which types of ticket, is set by policies. Policies are determined when the Kerberos service is installed or administered.
Note - You will frequently see the terms credential and ticket. In the greater Kerberos world, they are often used interchangeably. Technically, however, a credential is a ticket plus the session key for that session. This difference is explained in more detail in Gaining Access to a Service Using Kerberos.
The following sections further explain the Kerberos authentication process.
Initial Authentication: the Ticket-Granting Ticket
Kerberos authentication has two phases: an initial authentication that allows for all subsequent authentications, and the subsequent authentications themselves.
The following figure shows how the initial authentication takes place.
Figure 21-1 Initial Authentication for a Kerberos Session
Subsequent Kerberos Authentications
After the client has received the initial authentication, each subsequent authentication follows the pattern that is shown in the following figure.
Figure 21-2 Obtaining Access to a Service Using Kerberos Authentication
These steps make it appear that the server doesn't ever communicate with the KDC. The server does, though; it registers itself with the KDC, just as the first client does. For simplicity's sake, that part has been left out.
The Kerberos Remote Applications
The Kerberos-based (or “Kerberized”) commands that a user such as joe can use are the following:
These applications are the same as the Solaris applications of the same name. However, they have been extended to use Kerberos principals to authenticate transactions, thereby providing Kerberos-based security. See Kerberos Principals for information on principals.
These commands are discussed further in Kerberos User Commands.
A client in the Kerberos service is identified by its principal. A principal is a unique identity to which the KDC can assign tickets. A principal can be a user, such as joe, or a service, such as nfs or telnet.
By convention, a principal name is divided into three components: the primary, the instance, and the realm. A typical Kerberos principal would be, for example, joe/[email protected]. In this example:
The following are all valid principal names:
A realm is a logical network, similar to a domain, that defines a group of systems under the same master KDC. Figure 21-3 shows how realms can relate to one another. Some realms are hierarchical, where one realm is a superset of the other realm. Otherwise, the realms are nonhierarchical (or “direct”) and the mapping between the two realms must be defined. A feature of the Kerberos service is that it permits authentication across realms. Each realm only needs to have a principal entry for the other realm in its KDC. This Kerberos feature is called cross-realm authentication.
Figure 21-3 Kerberos Realms
Each realm must include a server that maintains the master copy of the principal database. This server is called the master KDC server. Additionally, each realm should contain at least one slave KDC server, which contains duplicate copies of the principal database. Both the master KDC server and the slave KDC server create tickets that are used to establish authentication.
The realm can also include a Kerberos application server. This server provides access to Kerberized services (such as ftp, telnet, rsh and NFS). If you have installed SEAM 1.0 or 1.0.1, the realm might include a Kerberos network application server, but this software was not included with these releases.
Figure 21-4 A Typical Kerberos Realm