When an initial client request reaches the CAS infrastructure, the CAS handling the request will authenticate the request and craft an authentication cookie for the client, which is then sent by the client with each subsequent request.
That authentication cookie is encrypted using the server’s SSL certificate that is configured for IIS. If persistence were to be configured, those requests would reach the same CAS over and over. As a result, that CAS would be able to decrypt and read the authentication cookie, because it was encrypted with its own certificate in the first place.
However, as we mentioned earlier, Exchange Server 2013 doesn’t require any persistence. This could cause subsequent requests to reach a different CAS. Without additional configuration, this would mean that subsequent requests potentially would need to be re-authenticated and as such result in an authentication pop-up or additional delay for handling the authentication.
The solution here is actually as simple as it is elegant. By configuring the same SSL certificate on each of the Client Access servers, you ensure that every CAS is able to decrypt the authentication cookie and thus can authenticate traffic without having to challenge the client for credentials.
Маханизм обеспечения балансировки на CAS-серверах за счет общего сертификата. Как результат не появляется окно с требованием аутентификации при переподключении к другому CAS-серверу.