Helping to Secure Communication: Client to Front-End Server

To help secure data transmitted between the client and the front-end server, it is highly recommended that the front-end server be SSL-enabled. Additionally, to ensure that user data is always secure, access to the front-end server without SSL should be disabled (this is an option in the SSL configuration). When using basic authentication, it is critical to protect the network traffic by using SSL to protect user passwords from network packet sniffing.

It is recommended that you obtain an SSL certificate by purchasing a certificate from a number of third-party certification authorities. Purchasing a certificate from a certification authority is the preferred method because the majority of browsers already trust many of these certification authorities.

Alternately, you can use Microsoft Certificate Server to install your own certification authorities. Although installing your own certificate authority may be less expensive, browsers will not trust your certificate, and users will receive a warning message indicating that the certificate is not trusted.

For more information, see Microsoft Knowledge Base article 320291, "XCCC: Turning on SSL for Exchange 2000 Server Outlook Web Access."

Configuring SSL in a Front-End and Back-End Topology

You do not need to configure SSL on back-end servers when using a front-end server, because the front-end server does not support using SSL to communicate with back-end servers. You can configure SSL on the back-end servers for use by clients that are directly accessing them.

When HTTP is used to access data, back-end servers need to generate absolute URLs, such as a list of URLs for the messages in a user's inbox. If SSL is used between the client and the front-end server, the back-end server needs to know this, so it can formulate URLs using HTTPS instead of HTTP. If SSL decryption is done on the front-end server, the front-end server knows SSL was used, and it notifies the back-end server of this by passing an HTTP header that says, "Front-End-Https: on" in all requests to the back-end server.

If there is a separate server between the client and the front-end server that is offloading the SSL decryption, the front-end server is unaware that the original request was made using SSL. In this case, that server must be able to pass the "Front-End-Https: on" header to the front-end server, which then passes it to the back-end server. ISA Server supports this. For information about how to enable this, see the Microsoft Knowledge Base article 307347, "Secure OWA Publishing Behind ISA Server May Require Custom HTTP Header."

As an alternative, you can configure SSL between the SSL decryption server and the front-end server. However, if you added that separate server to offload the additional traffic caused by SSL encryption and decryption, this method defeats that purpose. This method would still allow that separate server to filter the traffic.

SSL Accelerators

There is a decrease in performance involved in setting up and tearing down SSL connections, so you may want to investigate adding an SSL accelerator to your front-end and back-end topology.

SSL accelerators generally come in two forms:

• An SSL accelerator network card you can place on each front-end server.

• A separate device or computer you place between the clients and the front-end servers. An example of this is the Microsoft Internet Security and Acceleration Server 2000 Feature Pack 1 Service Pack 1 (ISA). An accelerator such as this supports adding the "Front-End-Https: On" header for Outlook Web Access.

Accelerator cards are generally used directly on the front-end server, and they offload the encryption and decryption overhead. This increases the throughput of each connection and decreases the amount of work the software on the server must do.

External accelerator devices sit between the clients and the front-end servers. Traffic coming from the client is decrypted on the accelerator device and sent to the front-end server unencrypted. Likewise, traffic from the front-end server is sent to the accelerator device unencrypted, and then it is encrypted for transmission to the client.

The most important factor to consider when choosing what type of SSL accelerator to use is the number of front-end servers in your topology. If you have a small number of front-end servers, adding SSL accelerator cards to each of them is a simple, cost-effective way to offload SSL duties. Because the SSL decryption is done on the front-end server, there is no need for extra configuration of the "Front-End-Https: on" header for Outlook Web Access.

For a large number of front-end servers, the cost of additional accelerator cards and the administrative cost of storing and configuring SSL certificates on each server eventually is not to be cost effective. In this case, a separate SSL accelerator device may be a more cost effective option for your topology because it needs to be configured only once, regardless of the number of front-end servers. These devices generally cost more than an accelerator card, so weigh the options in your own topology to determine which to use. Keep in mind that for Outlook Web Access, an external SSL device must have be able to notify the front-end server that SSL was used with the "Front-End-Https: on" header.

SSL Offloading

If there is a separate server between the client and the front-end server that is offloading the SSL decryption, the front-end server is unaware that the original request was created using SSL. In this case, that server must be able to pass the "Front-End-Https: on" header to the front-end server, which then passes it to the back-end server.

If your SSL offloading server does not support adding a custom header, you can install an Internet Server Application Programming Interface (ISAPI) on the front-end server to add this header. For information, see the Microsoft Knowledge Base article 327800, "How to configure SSL Offloading for Outlook Web Access in Exchange 2000 Server and in Exchange Server 2003." Alternatively, you can configure SSL between the SSL decryption server and the front-end server. However, if you added that separate server to offload the additional traffic caused by SSL encryption and decryption, this method defeats that purpose. This method would still allow that separate server to filter the traffic.

A separate SSL accelerator device may be a more cost-effective option for your topology because it needs to be configured only once, regardless of the number of front-end servers. These devices generally cost more than an accelerator card, so weigh the options in your own topology to determine which to use. Keep in mind that for Outlook Web Access, an external SSL device must be able to notify the front-end server that SSL was used with the "Front-End-Https: on" header.

Forms-Based Authentication

If you are using forms-based authentication with SSL offloading, you will need to configure your Exchange front-end servers to be able to handle this scenario. For detailed instructions, see How to Enable Forms-Based Authentication When Using SSL Offloading.