2.5.4.1.5 Credential Delegation

  • Article

Credential delegation use case

Figure 21: Credential delegation use case

Goal: To securely delegate the user's credentials from a client application to the target server application.

Context of Use: To serve the client application request by using the client's credentials, the target server requires access to a service or resource on a network. However, either the target server cannot be accessed with Kerberos delegation, or the number of legitimate possible authorization configurations makes configuration inconvenient.

Direct Actor: The client application.

Primary Actor: The user.

Supporting Actors: The AA, the server application, the PKI, and the account DB.

Preconditions:

  • The user that started the client application is logged on to the client computer.

  • The identities of the client application and the server application are configured in the account DB.

  • The policies that are required to enable CredSSP authentication are configured on both the client and the server.

  • The server is configured with an X.509 certificate to establish a TLS session.

  • The client application, server application, and DC can communicate with each other.

Minimal Guarantee: When credential delegation fails, the client application or the user is notified with an error message that indicates the reason for the failure.

Success Guarantee: The user credentials are successfully delegated to the target server.

Trigger: A client application, such as a Remote Desktop client or a Web services client, triggers the CredSSP Protocol [MS-CSSP] as the preferred authentication protocol for delegating the user's credentials.

Main Success Scenario: Negotiation Leads to Kerberos

  1. The client and server applications establish an encrypted channel by using the TLS protocol, as described in [RFC2246].

  2. The client and server applications negotiate over the TLS-encrypted channel that was established in step 1, as described in section 2.5.5.2, and agree on Kerberos as the authentication protocol.

  3. By using the Kerberos protocol, as described in section 2.5.4.1.3, the client and server mutually authenticate each other and establish an encryption key.

  4. The client application sends the user's password or smart card PIN to the target server. This transaction is protected by using the Kerberos encryption key that was established in the preceding step.

Alternate Scenario: Negotiation Leads to NTLM

  1. Same as step 1 in the Main Success Scenario.

  2. The client and server applications negotiate over the TLS-encrypted channel that was established in step 1, as described in section 2.5.5.2, and agree on NTLM as the authentication protocol.

  3. By using the NTLM protocol, the identity of the client application is proven to the target server, as described in section 2.5.4.1.1, and an encryption key is established.

  4. The client application sends the user's password or smart card PIN to the target server. This transaction is protected by using the NTLM encryption key that was established in the preceding step.

Postcondition: The client application can successfully delegate the user's credentials to the target server.

Extensions: None.