Types of Tickets
Tickets have properties that govern how they can be used. These properties are assigned to the ticket when it is created, although you can modify a ticket's properties later. For example, a ticket can change from forwardable to forwarded. You can view ticket properties with the klist command. See "How to View Tickets".
Tickets can be described by one or more of the following terms:
| Forwardable/forwarded | A forwardable ticket can be sent from one host to another, obviating the need for a client to reauthenticate itself. For example, if the user david obtains a forwardable ticket while on user jennifer's machine, he can log in to his own machine without having to get a new ticket (and thus authenticate himself again). See "Example--Creating a Ticket" for an example of a forwardable ticket. |
| Initial | An initial ticket is a ticket that is issued directly, not based on a ticket-granting ticket. Some services, such as applications that change passwords, can require tickets to be marked initial in order to assure themselves that the client can demonstrate a knowledge of its secret key. An initial ticket indicates that the client has recently authenticated itself (instead of relying on a ticket-granting ticket, which might have been around for a long time). |
| Invalid | An invalid ticket is a postdated ticket that has not yet become usable. An invalid ticket will be rejected by an application server until it becomes validated. To be validated, a ticket must be presented to the KDC by the client in a TGS request, with the VALIDATE flag set, after its start time has passed. |
| Postdatable/postdated | A postdated ticket is a ticket that does not become valid until some specified time after its creation. Such a ticket is useful, for example, for batch jobs that are intended to be run late at night, since the ticket, if stolen, cannot be used until the batch job is to be run. When a postdated ticket is issued, it is issued as Invalid and remains that way until: its start time has passed, and the client requests validation by the KDC. A postdated ticket is normally valid until the expiration time of the ticket-granting ticket. However, if the ticket is marked renewable, its lifetime is normally set to be equal to the duration of the full life of the ticket-granting ticket. |
| Proxiable/proxy | At times, it is necessary for a principal to allow a service to perform an operation on its behalf. An example might be when a principal requests a service to run a print job on a third host. The service must be able to take on the identity of the client, but need only do so for that single operation. In that case, the server is said to be acting as a proxy for the client. The principal name of the proxy must be specified when the ticket is created. A proxiable ticket is similar to a forwardable ticket, except that it is valid only for a single service, whereas a forwardable ticket grants the service the complete use of the client's identity. A forwardable ticket can therefore be thought of as a sort of super-proxy. |
| Renewable | Because it is a security risk to have tickets with very long lives, tickets can be designated as renewable. A renewable ticket has two expiration times: the time at which the current instance of the ticket expires, and the maximum lifetime for any ticket. If a client wants to continue to use a ticket, the client renews it before the first expiration occurs. For example, a ticket can be valid for one hour, with all tickets having a maximum lifetime of 10 hours. If the client that is holding the ticket wants to keep it for more than an hour, the client must renew it within that hour. When a ticket reaches the maximum ticket lifetime (10 hours), it automatically expires and cannot be renewed. |
For information on how to view tickets to see what their attributes are, see "How to View Tickets".
Ticket Lifetimes
Any time a principal obtains a ticket, including a ticket-granting ticket, the ticket's lifetime is set as the smallest of the following lifetime values:
The lifetime value that is specified by the -l option of kinit, if kinit is used to get the ticket.
The maximum lifetime value (max_life) that is specified in the kdc.conf file.
The maximum lifetime value that is specified in the Kerberos database for the service principal that provides the ticket. In the case of kinit, the service principal is krbtgt/realm.
The maximum lifetime value that is specified in the Kerberos database for the user principal that requests the ticket.
Figure 12-1 shows how a TGT's lifetime is determined and where the four lifetime values come from. Even though this figure shows how a TGT's lifetime is determined, basically the same thing happens when any principal obtains a ticket. The only differences are that kinit doesn't provide a lifetime value, and the service principal that provides the ticket provides a maximum lifetime value (instead of the krbtgt/realm principal).
Figure 12-1 How a TGT's Lifetime is Determined
The renewable ticket lifetime is also determined from the minimum of four values, but renewable lifetime values are used instead, as follows:
The renewable lifetime value that is specified by the -r option of kinit, if kinit is used to obtain or renew the ticket.
The maximum renewable lifetime value (max_renewable_life) that is specified in the kdc.conf file.
The maximum lifetime renewable value that is specified in the Kerberos database for the service principal that provides the ticket. In the case of kinit, the service principal is krbtgt/realm.
The maximum lifetime renewable value that is specified in the Kerberos database for the user principal that requests the ticket.
Principal Names
Each ticket is identified by a principal name. The principal name can identify a user or a service. Here are examples of several principal names.
Table 12-4 Examples of Principal Names
Principal Name | Description |
|---|---|
root/boston.example.com@EXAMPLE.COM | A principal that is associated with the root account on an NFS client. This principal is called a root principal and is needed for authenticated NFS-mounting to succeed. |
host/boston.example.com@EXAMPLE.COM | A principal that is used by the Kerberized applications (klist and kprop, for example). This principal is called a host or service principal. |
username@EXAMPLE.COM | A principal for a user. |
username/admin@EXAMPLE.COM | An admin principal that can be used to administer the KDC database. |
nfs/boston.example.com@EXAMPLE.COM | A principal that is used by the NFS service. This principal can be used instead of a host principal. |
K/M@EXAMPLE.COM | The master key name principal. There is one master key name principal that is associated with each master KDC. |
kadmin/history@EXAMPLE.COM | A principal which includes a key used to keep password histories for other principals. Each master KDC has one of these principals. |
kadmin/kdc1.example.com@EXAMPLE.COM | A principal for the master KDC server that allows access to the KDC by using kadmind. |
changepw/kdc1.example.com@EXAMPLE.COM | A principal for the master KDC server that allows access to the KDC when you are changing passwords. |
krbtgt/EXAMPLE.COM@EXAMPLE.COM | This principal is used when you generate a ticket-granting ticket. |
How the Authentication System Works
Applications allow you to log in to a remote system if you can provide a ticket that proves your identity, and a matching session key. The session key contains information that is specific to the user and the service that is being accessed. A ticket and session key are created by the KDC for all users when they first log in. The ticket and the matching session key form a credential. While using multiple networking services, a user can gather many credentials. The user needs to have a credential for each service that runs on a particular server. For instance, access to the ftp service on a server named boston requires one credential. Access to the ftp service on another server requires its own credential.
The process of creating and storing the credentials is transparent. Credentials are created by the KDC that sends the credential to the requester. When received, the credential is stored in a credential cache.
Gaining Access to a Service Using SEAM
In order for a user to access a specific service on a specific server, the user must obtain two credentials. The first credential is for the ticket-granting service (known as the TGT). Once the ticket-granting service has decrypted this credential, the service creates a second credential for the server that the user is requesting access to. This second credential can then be used to request access to the service on the server. After the server has successfully decrypted the second credential, then the user is given access. The following sections describe this process in more detail.
Obtaining a Credential for the Ticket-Granting Service
To start the authentication process, the client sends a request to the authentication server for a specific user principal. This request is sent without encryption. There is no secure information included in the request, so it is not necessary to use encryption.
When the request is received by the authentication service, the principal name of the user is looked up in the KDC database. If a principal matches, the authentication service obtains the private key for that principal. The authentication service then generates a session key to be used by the client and the ticket-granting service (call it session key 1) and a ticket for the ticket-granting service (ticket 1). This ticket is also known as the ticket-granting ticket (TGT). Both the session key and the ticket are encrypted by using the user's private key, and the information is sent back to the client.
The client uses this information to decrypt session key 1 and ticket 1, by using the private key for the user principal. Since the private key should only be known by the user and the KDC database, the information in the packet should be safe. The client stores the information in the credentials cache.
During this process, a user is normally prompted for a password. If the password the user enters is the same as the password that was used to build the private key stored in the KDC database, then the client can successfully decrypt the information that is sent by the authentication service. Now the client has a credential to be used with the ticket-granting service. The client is ready to request a credential for a server.
Figure 12-2 Obtaining a Credential for the Ticket-Granting Service
Obtaining a Credential for a Server
To request access to a specific server, a client must first have obtained a credential for that server from the authentication service. See "Obtaining a Credential for the Ticket-Granting Service". The client then sends a request to the ticket-granting service, which includes the service principal name, ticket 1, and an authenticator that was encrypted with session key 1. Ticket 1 was originally encrypted by the authentication service by using the service key of the ticket-granting service.
Because the service key of the ticket-granting service is known to the ticket-granting service, ticket 1 can be decrypted. The information in ticket 1 includes session key 1, so the ticket-granting service can decrypt the authenticator. At this point, the user principal is authenticated with the ticket-granting service.
Once the authentication is successful, the ticket-granting service generates a session key for the user principal and the server (session key 2), and a ticket for the server (ticket 2). Session key 2 and ticket 2 are then encrypted by using session key 1. Since session key 1 is known only to the client and the ticket-granting service, this information is secure and can be safely sent over the network.
When the client receives this information packet, the client decrypts the information by using session key 1, which it had stored in the credential cache. The client has obtained a credential to be used with the server. Now the client is ready to request access to a particular service on that server.
Figure 12-3 Obtaining a Credential for a Server
