certificate based authentication using LTM

When you say "the certificate based authentication is not working", are you referring to the certificate-based authentication to the CAS server? If so, that is to be expected. While this does NOT specifically apply only to LTM, any time you terminate (and optionally re-encrypt) the SSL communications between a client and server with a proxy device, you will lose the client's certificate in the SSL handshake. The client sends its certificate with a digital signature signed with its private key, and since the proxy does not have access to the client's private key, the proxy cannot send the client's certificate in the server side SSL handshake. There are, however, many options to consider:

1. The LTM is a full proxy between OSI layers 4 through 7, so it not only proxies at layer 4 (TCP/UDP) and layer 7 (HTTP, etc.), but also at layers 5/6 (SSL/TLS). This allows the LTM to apply separate SSL "profiles" to each side of the conversation, each with potentially different authentication and cipher requirements. Further, once the LTM terminates the client side SSL, it has full access to the X.509 attributes of the client certificate. With this you can perform additional CRL, CRLDP, and OCSP revocation checks, and any other X.509 attribute evaluations you can think of, within iRules.

    

2. Exchange CAS servers also support Kerberos authentication, so with the Access Policy Manager (APM) module, you could offload client side SSL, request a client certificate, and then transform that into Kerberos authentication on the server side.

    

3. If none of the above are options for you, there is another method called "ProxySSL" that may do what you need. This method provides an SSL "man-in-the-middle" capability so that the client and server can continue to negotiate SSL between each other, and the LTM can "see" inside this encrypted payload. This would be useful for implementing content inspection security and cookie-based persistence.

    

4. If all else fails, you can remove the client and server SSL profiles from the LTM virtual server and let the client-server SSL pass through the proxy unaltered. Because you have no insight on the payload at the proxy layer, you'll be limited to things like source address persistence and anything you can evaluate at layer 4 (TCP).

    

Thanks Kevin for your reply. Yes the CAS server works with certificate based authentication. For first time users, a user certificate will be generated using AD certificate server and subsequent authentication happens only when the client device provides that certificate. We don't have APM module in our environment. I tried the proxy SSL feature but it doesn't seems to help. Will proxy SSL feature pass the traffic to backend servers without any modifications?

The current setup is working if no certificate is applied at LB level. Is there anyway we can block EWS traffic using iRule?

With the understanding that you cannot do certificate-based authentication to a server if a device in front of it terminates (and optionally re-encrypts) the SSL between the client and server, you have basically two options:

1. Let the proxy do the SSL offload and certificate consumption, and find another way to authenticate at the server. This is something that APM does particularly well, especially for Exchange and SharePoint. You may not have it in your architecture now, but it's definitely worth a look. The added benefit of an "authentication proxy" is that you can "pre-authenticate" users. You can do SSL offload, certificate revocation, and any other auth/security validations BEFORE a single packet ever touches the CAS server.

    

2. Simply don't offload SSL. If you remove the client and server SSL profiles from the VIP, the SSL will pass straight through from the client to the server. Of course doing this you lose all insight into the traffic and any significant ability to act on that traffic. You could also use the ProxySSL feature. Basically, you check the ProxySSL option and apply the backend server's PRIVATE key to a set of client and server SSL profiles, and then apply both to the VIP. The private key in the profiles allows the VIP to transparently negotiate the same session encryption key that the client and server will use, allowing it the ability to silently decrypt and re-encrypt the SSL without either party being the wiser. There are implications to this option though. You must allow the client and server to negotiate an end-to-end connection, so you can't have any preemptive processes inline, or any iRules that may switch server pool members based on some criteria. There is also a limitation, currently, with ProxySSL and the ciphers that it can support, so some clients and/or servers may have a problem using it. Otherwise, you can in fact do client certificate auth to CAS with ProxySSL. You'll want to get up to 11.3 HF5 at the least, as this version makes some significant improvements to ProxySSL.