How the Kerberos Service Works
This section provides an overview of the Kerberos authentication system.
From the user's standpoint, the Kerberos service is mostly invisible after the Kerberos session has been started. Commands such as ssh 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 request an NFS-mounted file), 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 NFS server. "Transparently" means that you do not need to explicitly request a ticket. The request happens when you attempt to access the server. Because only authenticated clients can get a ticket for a specific service, another client cannot access the NFS server 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 system 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 is set by policies, for example, to specify which users are allowed to obtain which types of ticket. Policies are determined when the Kerberos service is installed or administered.
Note - You will frequently see the terms credential and ticket. While they are often used interchangeably, technically a credential is a ticket plus the session key for that session.
The following sections further explain the Kerberos authentication process.
Initial Authentication: the Ticket-Granting Ticket
Kerberos authentication has two phases: an initial authentication that enables all subsequent authentications, and the subsequent authentications themselves.
The following figure shows how the initial authentication takes place.
Figure 4 Initial Authentication for a Kerberos Session
-
A client (a user, or a service such as NFS) begins a Kerberos session by requesting a ticket-granting ticket (TGT) from the Key Distribution Center (KDC). This request is often done automatically at login.
A ticket-granting ticket is needed to obtain other tickets for specific services. Think of the ticket-granting ticket as similar to a passport. Like a passport, the ticket-granting ticket identifies you and allows you to obtain numerous "visas" (tickets), which instead of granting access to foreign countries enable you to access remote systems or network services. Like passports and visas, the ticket-granting ticket and the other various tickets have limited lifetimes. The difference is that "Kerberized" commands notice that you have a passport and obtain the visas for you. You don't have to perform the transactions yourself.
Another analogy for the ticket-granting ticket is that of a three-day ski pass that is good at four different ski resorts. You show the pass at whichever resort you decide to go to and you receive a lift ticket for that resort as long as the pass has not expired. Once you have the lift ticket, you can ski all you want at that resort. If you go to another resort the next day, you once again show your pass and you get an additional lift ticket for the new resort. The difference is that the Kerberos-based commands notice that you have the weekend ski pass and get the lift ticket for you so you don't have to perform the transactions yourself.
-
The KDC creates a ticket-granting ticket and sends it back, in encrypted form, to the client. The client decrypts the ticket-granting ticket by using the client's password.
-
Now in possession of a valid ticket-granting ticket, the client can request tickets for all sorts of network operations, such as nfs or ssh, for as long as the ticket-granting ticket lasts. This ticket usually lasts for a few hours. Each time the client performs a unique network operation, it requests a ticket for that operation from the KDC.
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 5 Obtaining Access to a Service Using Kerberos Authentication
-
The client requests a ticket for a particular service, for example, to log in remotely to another system, from the KDC by sending the KDC its ticket-granting ticket as proof of identity.
-
The KDC sends the ticket for the specific service to the client.
Suppose user jdoe wants to access an NFS file system that has been shared with krb5 authentication required. Because jdoe is already authenticated (that is, jdoe already has a ticket-granting ticket), as jdoe attempts to access the files, the NFS client system automatically and transparently obtains a ticket from the KDC for the NFS service. To use a different Kerberized service, jdoe obtains another ticket, as in Step 1.
-
The client sends the ticket to the server.
When using the NFS service, the NFS client automatically and transparently sends the ticket for the NFS service to the NFS server.
-
The server allows the client access.
Although these steps imply that the server never communicates with the KDC, the server does register itself with the KDC, just as the first client does. For simplicity's sake, that section has been omitted.
Kerberos Authentication of Batch Jobs
Batch jobs, such as cron, at, and batch, are delayed execution processes. In a Kerberos environment, all processes including delayed execution processes require credentials. However, users' credentials are relatively short-lived. By default, user credentials are valid for 8 hours and renewable for as long as a week. These times are designed to limit the exposure of sensitive keys to malicious users, but can prevent the execution of jobs at arbitrary times.
In Oracle Solaris, batch jobs that access Kerberos services can run without exposing the user's longterm key. The solution involves storing credentials that include the Kerberos service, the user name, and the client host name in a per-session user credential cache. A PAM module is used to authenticate the batch job. Which services a host can obtain tickets for can be centrally stored in the LDAP directory server.
For more information, see the pam_krb5_keytab(5) and pam_gss_s4u(5) man pages and Configuring Delayed Execution for Access to Kerberos Services.
Kerberos, DNS, and the Naming Service
The Kerberos service is compiled to use DNS to resolve host names. The nsswitch service is not checked at all to resolve host names.