2.5.4.1.4 Delegation of Authentication
Delegation of authentication is accomplished in one of four ways. In the first, the client gets a service ticket for the back-end server and gives it to the front-end server. Tickets obtained in this way—by using the client as a proxy—are called proxy tickets. The difficulty with using proxy tickets is that the client is provided with the name of the back-end server, and the client cannot determine whether to allow the delegation. Windows clients do not use the proxy tickets mechanism.
The second method of delegation overcomes the difficulty with using proxy tickets. It allows the client to give the front-end server a TGT that the front-end server can use to request service tickets for the back-end server as they are required. Service tickets that are obtained in this way—with credentials forwarded by a client—are called forwarded tickets. The Kerberos policy that an administrator sets for the domain determines whether the KDC allows clients to obtain proxy tickets or TGTs that can be forwarded.
In the other two methods, the front-end server does not require the user to forward either the TGT or the proxy tickets to access the services of the back-end server. In other words, a user does not have to have either a TGT or proxy service tickets. This initial condition means that the user is not required to use the Kerberos protocol to authenticate.
The following use cases describe how the client delegates authentication to a front-end server by informing the KDC that the front-end server is authorized to represent the client to access the back-end server resources.

Figure 20: Delegation of authentication use case
Goal: To delegate authentication of the client identity to the front-end server to access the resources or services of the back-end server on behalf of the client's identity.
Context of Use: The front-end server has to access resources or services on the back-end server on behalf of the identity of the client application to fulfill the client application request.
Direct Actor: The client application or the front-end server depending on the chosen delegation mechanism.
Primary Actor: The user that is running the client application.
Supporting Actors: The AA, the back-end server, the PKI, and the account DB.
Preconditions:
The user that started the client application is authenticated.
The identities of the front-end server and the back-end server are configured in the account DB.
The client application, front-end server, back-end server, and AA can communicate with each other.
The client application has obtained the forwarded TGT and service ticket for the front-end server ([MS-SFU] section 1.3.3).
Minimal Guarantee: The front-end server receives an error message from the AA that indicates the reason for the failure.
Success Guarantee: The front-end server can prove the identity of the user that is running the client application to the back-end server.
Trigger: The front-end server has to access a protected resource or a service on the back-end server on behalf of the identity of the client application.
Postcondition: The front-end server has successfully proven the identity of the user that is running the client application to the back-end server.