test

System Administration Guide, Volume 2

Ticket Reference

The following section presents additional information about tickets.

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 jennifer's machine, he can log in to his own machine without having to get a new ticket (and thus authenticate himself again). (See XREF for an example of a forwardable ticket.) Compare a forwardable ticket to a proxiable ticket, below.

initial

An initial ticket is one 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 -- because 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. (See postdated, below.) It will be rejected by an application server until it becomes validated. To be validated, it 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 one that does not become valid until some specified time after its creation. Such a ticket is useful, for example, for batch jobs 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. (See invalid, above.) A postdated ticket is normally valid until the expiration time of the ticket-granting ticket; however, if it is marked renewable, its lifetime is normally set to be equal to the duration of the full life of the ticket-granting ticket. See renewable, below.

proxiable/proxy

At times it can be 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, it 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 ten hours. If the client 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 following figure shows how a TGT's lifetime is determined and illustrates where the four lifetime values come from. Even though the 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 providing the ticket provides a maximum lifetime value (instead of the krbtgt/realm principal).

Figure 23-1 How a TGT's Lifetime Is Determined

Graphic

The renewable ticket lifetime is also determined from the minimum of four values, but renewable lifetime values are used instead:

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 of the principal names.

Table 23-4 Examples of Principal Names

Principal Name 

Description 

root/boston.acme.com@ACME.COM

A principal associated with the root account on an NFS client. This is called a root principal and is needed for authenticated NFS-mounting to succeed.

host/boston.acme.com@ACME.COM

A principal used by the Kerberized applications (klist for example) or services (such as the NFS service).

username@ACME.COM

A principal for a user. 

username/admin@ACME.COM

An admin principal that can be used to administer the KDC database.

nfs/boston.acme.com@ACME.COM

A principal used by the nfs service. This can be used instead of a host principal.