Forum Discussion
am_gli
Altostratus
AltostratusCertificate as second factor for ActiveSync
Hi,
we have a F5 in front of an Exchange 2016 Cluster, which does the LB (configured via iApp / the https-combined-pool-selection-irule). There is no APM in use. Since ActiveSync is one of the last "open" services that has no second factor for authentication, we'd like to implement some kind of simple client-certificate check against the CA.
In principle our (simple) approach would be:
- if /ms-active-sync is called and no client cert exists -> reset SSL-Handshake and switch to another SSL-profile
- other SSL-profile has "client cert: require" and a CA that it checks against
- if this succeeds, the client request (with the Auth details) is forwarded as usual tothe Exchange-Server, which handles the authentication with username/pw (normal EAS login)
Unfortunately I'm not sure if EAS-client is able to present a certificate at request from F5. I know about a guide that describes how to switch EAS to cert-auth on Exchange servers, but that would be "cert-only" (no additional user/pw).
But I assume this "reconfigures the client" , so that it presents a cert for authentication, and leaves out the part with user/pw.
But I'm not sure if the client would present a certificate if requested by F5 only, or if this would terminate in an error.
Anyone experienced with such a setup?
f51Cirrostratus
Your approach to implementing a client-certificate check for ActiveSync on your F5 load balancer in front of an Exchange 2016 Cluster sounds reasonable. However, the success of this setup largely depends on whether the Exchange ActiveSync (EAS) client can present a certificate when requested by F5. In a typical setup, the EAS client does not present a certificate unless it's explicitly configured to do so. This configuration is usually done on the Exchange server, not on the F5 device. When the Exchange server is configured for certificate-based authentication (CBA), the EAS client will present a certificate during the SSL/TLS handshake process. In your case, you want the client to present a certificate when requested by the F5 device, not by the Exchange server. This scenario is less common and may not work as expected unless the EAS client is configured to present a certificate regardless of the server requesting it.
am_gliThanks for the reply - but what would be a common approach to resolve this?
The setup with an Exchange-Server + F5 and security-aware customers that don't want any 1F-Authentication from the Internet to their AD should be something that exists in thousands of setups worldwide. I'm not sure how others have achieved this? Because a 2F-auth with Tokens for EAS is not an option - and if you'd activate it on Exchange side, you'd have to disable SSL-Termination on F5, so that Exchange receives the client-certificate for authentication. That way, you remove many advantages that F5 provides (e.g. ASM).