This topic explains how a client principal in one cell is authenticated by the KDS in a peer cell, so that the client principal may communicate with a server principal that is a member of the foreign cell. The style of description is the same as in the walkthroughs earlier in this topic, though no figures are used here.
1. A client principal, having already been authenticated in the normal way by the KDS and privilege service in its home cell and acquired its PTGT, requests its local TGS for a service ticket targeted to a server in a foreign cell. The client specifies the server principal by its fully qualified principal name, which includes the name of the foreign cell.
2. The client's security runtime makes a request to the client's local TGS for a service ticket to the foreign server. The TGS recognizes by the server's principal name that it is foreign, so this TGS cannot directly issue the desired service ticket. Instead, it issues a so-called cross-cell TGT (XTGT), which is targeted to the surrogate shared between the two cells (that is, it is encrypted in the surrogate's secret key). The EPAC data in the client's PTGT is copied into the XTGT, and the local TGS returns the XTGT to the client. (For simplicity, we deal here only with simple case of EPAC data, not a delegation EPAC chain.)
3. The client receives the XTGT, recognizes that it is not targeted to the application server it had requested, and proceeds to send a request to the foreign TGS for a service ticket to the foreign privilege service, this time presenting the XTGT (instead of its original TGT) as proof of authentication. Upon receiving this request, the foreign TGS decrypts it by using the surrogate's secret key, and returns to the client a service ticket to the foreign privilege service. (Note how knowledge of the surrogate's shared key makes it possible for the two TGSs to cooperate in this way.)
4. The client's security runtime now sends this service ticket to the foreign privilege service, to obtain a cross-cell privilege TGT (XPTGT). This XPTGT contains the client's original EPAC, and is encrypted with the secret key of the foreign privilege service.
5. After the client principal receives the XPTGT, it sends it to the foreign TGS, requesting a service ticket to the foreign server principal it was originally interested in. From this point on, the protocol goes exactly as it would in the case of a client principal in the server's cell requesting a service ticket to that server (as previously described). Similarly, the client principal may reuse the XPTGT to acquire service tickets to any other servers in the foreign cell.