System Administration Guide: Security Services

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 being forwardable to being forwarded. You can view ticket properties with the klist command. See Viewing Kerberos 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 host, 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 26–1 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 ticket–granting service 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, because 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. The principal name of the proxy must be specified when the ticket is created. The Solaris release does not support proxiable or proxy tickets.

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, which is one week. 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 the attributes of tickets, see Viewing Kerberos Tickets.

Ticket Lifetimes

Any time a principal obtains a ticket, including a ticket–granting ticket (TGT), 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. By default, kinit used the maximum lifetime value.
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 27–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 27–1 How a TGT's Lifetime is Determined

Diagram shows that a ticket lifetime is the smallest
value allowed by the kinit command, the user principal, the site default,
and the ticket granter.

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.

Kerberos 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 27–4 Examples of Kerberos Principal Names


Principal Name	Description
`changepw/kdc1.example.com@EXAMPLE.COM`	A principal for the master KDC server that allows access to the KDC when you are changing passwords.
`clntconfig/admin@EXAMPLE.COM`	A principal that is used by the `kclient` installation utility.
`ftp/boston.example.com@EXAMPLE.COM`	A principal used by the `ftp` service. This principal can be used instead of a `host` principal.
`host/boston.example.com@EXAMPLE.COM`	A principal that is used by the Kerberized applications (`klist` and `kprop`, for example) and services (such as `ftp` and `telnet`). This principal is called a `host` or service principal. The principal is used to authenticate NFS mounts. This principal is also used by a client to verify that the TGT that is issued to the client is from the correct KDC.
`K/M@EXAMPLE.COM`	The master key name principal. One master key name principal is associated with each master KDC.
`kadmin/history@EXAMPLE.COM`	A principal that 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`.
`kadmin/changepw.example.com@EXAMPLE.COM`	A principal that is used to accept password change requests from clients that are not running a Solaris release.
`krbtgt/EXAMPLE.COM@EXAMPLE.COM`	This principal is used when you generate a ticket-granting ticket.
`krbtgt/EAST.EXAMPLE.COM@WEST.EXAMPLE.COM`	This principal is an example of a cross-realm ticket-granting ticket.
`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.
`root/boston.example.com@EXAMPLE.COM`	A principal that is associated with the `root` account on a client. This principal is called a `root` principal and provides `root` access to NFS mounted file systems..
`username@EXAMPLE.COM`	A principal for a user.
`username/admin@EXAMPLE.COM`	An `admin` principal that can be used to administer the KDC database.