2.5.4.1.1 Client Authentication

  • Article

This use case describes how a server application authenticates the user identity of the client application before it allows access to its protected resource or services.

Client authentication use case

Figure 17: Client authentication use case

Goal: To verify the identity of the client application.

Context of Use: The user has to access a service on a network that requires verification of client identities.

Direct Actor: The client application.

Primary Actor: The user.

Supporting Actors: The AA, the server application, 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 client application, server application, and DC can communicate with each other.

Minimal Guarantee: When client authentication fails, the client application receives an error message that indicates the reason for the failure.

Success Guarantee: The server application has verified the identity of the client application.

Trigger: The user has to access a protected resource or a service on the server computer.

Main Success Scenario: Negotiation leads to the use of Kerberos.

  1. The client and server application negotiate as described in section 2.5.5.2 and agree on Kerberos as the authentication protocol.

  2. The identity of the client application is proven to the AA as described in section 2.5.5.1.

  3. The client application sends the target server application's identity and the TGT material that was obtained in step 2 to the AA to request a service ticket for the service application.

  4. The AA locates the identity of the server application in its account DB and returns a service ticket and a session key to the client application.

  5. The client application builds the authenticator by using a session key and sends the service ticket plus the authenticator to the target application.

  6. The server application verifies the authenticity of the client application identity and extracts the group information from the service ticket.

Alternative Scenario: Negotiation leads to the use of Kerberos, and FAST mode is supported and configured on both the Authentication Client and the AA.

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

  2. The identity of the client computer is proven to the AA as described in the Main Scenario in section 2.5.5.1.1 or section 2.5.5.1.2, and a TGT for the computer is obtained.

  3. The identity of the user is proven to the AA as described in the Alternative Scenario in section 2.5.5.1.1.

  4. The client application constructs the FAST TGS-REQ message with the target server application's identity and the TGT material that was obtained in step 2 and then sends it to the AA to request a service ticket for the target server application.

  5. The AA locates the identity of the server application in its account DB and returns a service ticket and a session key to the client application in a FAST TGS-REP message.

  6. The client application builds the authenticator by using a session key and sends an AP-REQ ([RFC4120] section 5.5.1) message that contains the service ticket plus the authenticator to the target application.

  7. The server application verifies the authenticity of the client application identity and extracts the group information and claims from the service ticket.

Alternative Scenario: Negotiation leads to the use of Kerberos, and Compound Identity is supported and configured on the Authentication Client, the AA, and the Application Server.

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

  2. The identity of the client application is proven to the AA as described in the Alternative Scenario in section 2.5.5.1.1.

  3. The client application constructs a compound identity TGS-REQ and sends it to the AA to request a service ticket for the server application.

  4. The AA receives a compound identity TGS-REQ for a server application that supports compound identity, verifies the request, and then adds the computer's authorization data to the privilege attribute certificate (PAC) in the service ticket. The AA returns a service ticket and a session key to the client application.

  5. The client application builds the authenticator by using a session key and sends the service ticket plus the authenticator in an AP-REQ message to the target application.

  6. The server application verifies the authenticity of the client application identity and extracts the group information, user claims, and device claims from the service ticket.

Alternative Scenario: Negotiation leads to the use of NTLM

  1. The client and server application negotiate authentication protocols, as described in section 2.5.5.2, and agree on NTLM as the authentication protocol.

  2. The client application requests the server to establish an authenticated session by using its identity.

  3. The server sends back a challenge message that contains a nonce.

  4. The client application builds a response message by using the challenge and the key that is derived from the user's password and sends the response message to the server.

  5. The server application verifies the client identity by sending the response message that is received in the preceding step to the AA.

  6. The AA validates the submitted response message by interacting locally with the account DB.

  7. The AA responds to the server with the group and other information.

  8. The server application returns a success response to the client application.

Postconditions: The identity of the client application is proven to the server application. Both the client and the server application have a shared session key for further secure communication.

The following alternative scenarios apply when the client and the server application are configured with the Digest or SSL/TLS authentication protocols and are not configured with the Negotiate authentication protocol.

Alternative Scenario: Digest Protocol Extensions

  1. The client application sends an application-protocol-specific request to access a protected resource of the server application.

  2. The server application validates the request and returns a digest challenge message to the client. This message includes the randomly generated nonce and the domain name of the server.

  3. The client obtains the user name (for example, User123) and a password for the user and constructs a response to the server's challenge. In the digest response, the client proves that it has acquired the user's password by performing a keyed hash over the user name, nonce, and other fields (the password is fed into the hash).

  4. The server application sends the response and the nonce that was received in step 3 to the AA for validation.

  5. The AA validates the request message by interacting locally with the account DB and responds to the server application with the group membership information.

  6. The server application sends the response messages that were received in step 5 to the client application.

Extensions: None.