2.5.5.3 S4U2self Mechanism: Get a Service Ticket for a Front-End Server
This use case describes how a front-end server obtains a service ticket to itself on behalf of the identity of a client application by using the S4U2self mechanism ([MS-SFU] section 1.3.1) when the identity of the client application is proven to the front-end server by some means other than Kerberos.
Figure 26: The front-end server obtains service ticket to itself by using the S4U2self mechanism
Goal: To get a service ticket for a service application on the front-end server.
Context of Use: The user is authenticated to the service application by using a non-Kerberos protocol, and the front-end service application is required to get a service ticket to itself to serve the client application request. For example, the front-end service application requires group information to perform authorization checks, or it requires a service ticket to use in S4U2Proxy (to contact a back-end service).
Direct Actor: The front-end server.
Primary Actor: The service application that is running on the front-end server.
Supporting Actors: The AA, the account DB, and the PKI.
Preconditions:
The front-end server has obtained the identity of the user that is running the client application: either the user's certificate or the user name and user's domain name.
The identity service application is configured in the account DB.
The service application is authenticated to the AA (the KDC) and has a valid TGT.
The front-end server and the AA can communicate with each other.
The client application and the front-end server can communicate with each other.
Minimal Guarantees: The front-end server application fails to get a service ticket to itself on behalf of the identity of the client application. The front-end server application receives an error message that indicates the reason for the failure.
Success Guarantee: The front-end server application gets a service ticket, which contains group information, to itself on behalf of the identity of the client application.
Trigger: When the client application attempts to access protected resources or services on the front-end server by proving its identity through the use of a non-Kerberos protocol, the front-end server has to get a service ticket to itself on behalf of the identity of the client application to serve the client's request.
Main Success Scenario:
The front-end server makes a request to the AA (the KDC) for a service ticket to itself on behalf of the identity of the client application by using the S4U2self extension. The front-end server presents the identity of the client application in either of the following forms:
A user name and a user's domain name.
Or
The user's certificate.
The KDC validates the request and returns a service ticket to the front-end server on behalf of the client's identity.
Postcondition: The front-end server application can successfully get a service ticket to itself on behalf of the identity of the client application.
Extensions: None.