2.5.4.3.1 Client Authentication

  • Article

This use case describes how a client application authenticates itself in a cross-forest environment.

Client authentication in a cross-forest environment

Figure 23: Client authentication in a cross-forest environment

Goal: To verify the identity of the client application.

Context of Use: The user has to access a service or resource on a different forest that requires verification of client identities.

Direct Actor: The client application.

Primary Actor: The user.

Supporting Actors: FAA1, AA1, DB #1, FAA2, AA2, DB #2, GC, and DNS.

Preconditions:

  • The user that started the client application is logged on to the client computer, which is in forest1.

  • The identities of the client application and the client computer are configured in DB #1, and the identity of the server application is configured in DB #2.

  • Bidirectional forest trust is established between forest1 and forest2.

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 that resides in domain2 in forest2.

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

  1. The client and server applications 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 AA1, as described in the Main Success Scenario 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 AA1 to request a service ticket for the server application.

  4. AA1 cannot find an entry for the server application identity in DB #1 and requests the GC server to verify the server application identity. The GC server replies that the service is located in forest2; therefore, AA1 sends the referral ticket to the root authority of forest1 (FAA1).

  5. On receiving the referral ticket, the client application locates FAA1 and sends the TGS request with the received referral ticket.

  6. FAA1 double-checks with the local GC as to whether the identity of the server application is in forest1. After FAA1 confirms that the identity does not exist in forest1, FAA1 sends the referral ticket to the root authority of forest2 (FAA2).

  7. FAA2 double-checks with the local GC as to whether the identity of the server application is in forest2. After FAA2 confirms that the identity of the server application exists in domain2, FAA2 sends the referral ticket to domain2 (AA2) in forest2.

  8. AA2 validates the client’s identity through the referral TGT, filters out all SIDs that are not local to the client’s identity home forest, and sends the response with the service ticket of the requested server application 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.

Extensions: None.