|
|
| Previous | Table of Contents | Next |
Applications occasionally might need to obtain tickets for use much later. A batch submission system, for example, would need tickets to be valid at the time the batch job is serviced. Holding valid tickets in a batch queue is dangerous, however, because they stay online longer, becoming more prone to theft. Postdated tickets provide a way to obtain these tickets from the Key Distribution Center at job submission time, but to leave them dormant until they are activated and validated by a further request of the Key Distribution Center. If a ticket theft were reported in the interim, the Key Distribution Center would refuse to validate the ticket, and the thief would be foiled.
The MAY-POSTDATE flag in a ticket normally is interpreted only by the Ticket Granting Service. Application servers can ignore it. This flag must be set in a Ticket Granting Ticket in order to issue a postdated ticket based on the presented ticket. It is reset by default. A client can request it by setting the ALLOW-POSTDATE option in the KRB_AS_REQ message. This flag does not permit a client to obtain a postdated Ticket Granting Ticket. Postdated Ticket Granting Tickets can be obtained only by requesting the postdating in the KRB_AS_REQ message.
When a postdated ticket is issued, the life (end time-start time) of the ticket is the remaining life of the Ticket Granting Ticket at the time of the request, unless the RENEWABLE option also is set, in which case it can be the full life (end time-start time) of the Ticket Granting Ticket. The Key Distribution Center can limit how far in the future a ticket may be postdated.
The POSTDATED flag indicates that a ticket has been postdated. The application server can check the authtime field in the ticket to see when the original authentication occurred. Some services might reject postdated tickets, or accept them only within a certain period after the original authentication. When the Key Distribution Center issues a POSTDATED ticket, it also is marked as INVALID, so that the application client must present the ticket to the Key Distribution Center to be validated before use.
Sometimes, a principal might need to enable a service to perform an operation on its behalf. The service must be able to take on the identity of the client, but only for a particular purpose. A principal can permit a service to take on the principal’s identity for a particular purpose by granting it a proxy.
The PROXIABLE flag in a ticket normally is interpreted only by the Ticket Granting Service. Application servers can ignore it. When set, this flag gives the Ticket Granting Server the go-ahead to issue a new ticket (but not a Ticket Granting Ticket) with a different network address based on this ticket. This flag is set by default. This flag enables a client to pass a proxy to a server to perform a remote request on its behalf. A print service client, for example, can give the print server a proxy to access the client’s files on a particular file server to satisfy a print request.
To complicate the use of stolen credentials, Kerberos tickets usually are valid only from those network addresses specifically included in the ticket. You can request or issue tickets with no network addresses specified, but doing so is not recommended. Therefore, a client that wants to grant a proxy must request a new ticket valid for the network address of the service to be granted the proxy.
The PROXY flag is set in a ticket by the Ticket Granting Server when it issues a proxy ticket. Application servers may check this flag and require additional authentication from the agent before presenting the proxy in order to provide an audit trail.
Authentication forwarding is an instance of the proxy case where the service is granted complete use of the client’s identity. A user might log in to a remote system, for example, and want authentication to work from that system as if the login were local.
The FORWARDABLE flag in a ticket normally is interpreted only by the Ticket Granting Service. Application servers can ignore it. The FORWARDABLE flag has an interpretation similar to that of the PROXIABLE flag, except Ticket Granting Tickets also can be issued using different network addresses. This flag is reset by default, but users can request that it be set by setting the FORWARDABLE option in the Authentication Server request when they request the initial Ticket Granting Ticket.
When set, the FORWARDABLE flag permits authentication forwarding without requiring the user to reenter a password. If the flag is not set, then authentication forwarding is not permitted. The same end result still can be achieved if the user engages in the Authentication Server exchange with the requested network addresses and supplies a password.
The FORWARDED flag is set by the Ticket Granting Server when a client presents a ticket with the FORWARDABLE flag set and requests it be set by specifying the FORWARDED Key Distribution Center option and supplying a set of addresses for the new ticket. It also is set in all tickets issued based on tickets with the FORWARDED flag set. Application servers might want to process FORWARDED tickets differently from non-FORWARDED tickets.
Three flags indicate information about the user’s authentication status. INITIAL, PRE-AUTHENT, and HW-AUTHENT are set at the time of authentication.
INITIAL is set by the Authentication Server whenever a ticket is issued as a result of an authentication. This flag does not carry forward onto future tickets, so it serves to indicate that this ticket was authenticated directly, which is useful for applications that require a specific authentication prior to proceeding, such as the login or password changing programs.
Note: Some of the possible Kerberos startup cycles can result in a ticket being issued before the user is authenticated. These tickets should be usable only by the legitimate user. The PRE-AUTHENT flag is set after a specific authentication takes place.
Finally, the flag HW-AUTHENT indicates that the user was hardware authenticated. Hardware authentication through the use of tokens or biometrics generally is stronger than simple password authentication. Applications dealing with particularly sensitive information or large financial transactions should be configured to request a hardware authentication.
| Previous | Table of Contents | Next |