4.2 S4U2self Multiple Realm Example

The multiple-realm scenario requires extra KRB_TGS_REQ and KRB_TGS_REP message exchanges. The service retrieves a S4U2self service ticket for the user from the service's KDC. To do so, the service retrieves a TGT for the user to the service's TGS. This is accomplished by first obtaining a TGT to the user's TGS and then following referrals from the user's TGS to the service's TGS.

There are two preconditions to the following figure. The first is that the service has already authenticated to its KDC and has a TGT to its TGS. The second precondition is that the service has identified the realm for the user account. One approach for finding the user's realm is through the use of KRB_AS_REQ messages and using the information returned from the KDC, as specified in [Referrals].

In the following figure, TGS A represents the TGS in the service's realm. TGS B represents the TGS in the user's realm.

S4U2self Multiple Realm Example

Figure 5: S4U2self Multiple Realm Example

  1. The service sends a request to its TGS, TGS A, for a TGT to TGS B. No S4U2self information is included in this request.

  2. TGS A responds with the cross-realm TGT to TGS B. If TGS B was not the user's realm but was instead just a realm closer, then the service would send a KRB_TGS_REQ message to TGS B to get a TGT to the next realm.

  3. The service now uses the TGT to TGS B to make the S4U2self request in the KRB_TGS_REQ. The service uses the PA-FOR-USER padata type in the request to indicate the user information in the S4U2self request.

  4. TGS B creates a PAC with the user's authorization information (as specified in [MS-PAC] section 3) and returns it in a TGT referral in the KRB_TGS_REP message. TGS B cannot create the service ticket. TGS B does not possess the service's account information, because the service is part of the realm served by TGS A.

    If there are more TGSs involved in the referral chain, steps 3 and 4 will be repeated to follow the chain.

  5. The server uses the TGT from the referral from step 4 and uses the PA-FOR-USER padata type to request the service ticket to itself on behalf of the user.

  6. TGS A creates the service ticket for the user to the service and returns it. The PAC returned in this step will contain the appropriate combination of authorization data placed in the PAC by TGS B in step 4 and the data from TGS A in step 6, as specified in [MS-PAC] section