Using SSL with Outlook Web Access


You should at least enable the use of SSL for your Outlook Web Access users because the initial communication between an Outlook Web Access client and server requires the user s credentials to be sent to the server. If you re using basic Web authentication, the data will go in the clear, so anyone between client and server can read it. That presents a definite security risk, which you can easily avoid by using SSL for your Outlook Web Access sessions. For example, the Microsoft internal Outlook Web Access servers require the use of SSL, period. However, it s important that you know one critical fact about SSL with FE/BE configurations: SSL cannot be used between the FE and BE servers. That means that in the default configuration, traffic between FEs and BEs is completely in the clear. To fix this, you ll need to do one of two things: put the FE and BE on the same, hardened segment, or use IPSec, as discussed later in this chapter.

Enabling SSL for OWA

If you want to force the use of SSL on your server, the process is fairly straightforward. First, you ll need to obtain and install a secure certificate for your server (a process described in more detail in Microsoft Knowledge Base articles 290625 and 298805, as well as in Chapter 15, Securing POP and IMAP ). Once you ve installed your certificate, you need to turn on and enforce SSL by doing the following:

  1. Use the Internet Information Services (IIS) Manager snap-in to open the Properties dialog box for the Default Web Site object. On the Web Site tab, click Advanced in the Web Site Identification control group . That opens the Advanced Multiple Web Site Configuration dialog box.

  2. Verify that the Multiple SSL Identities For This Web Site list shows an entry for port 443. If not, click Add to add one. Click OK to close the dialog box.

  3. Click the Directory Security tab. In the Secure Communications control group, the Edit button will be enabled if you correctly installed your server s SSL certificate. (If not, you ll need to fix that before proceeding.) Click Edit. In the resulting dialog box, select the Require Secure Channel (SSL) check box. Optionally, you can select a minimum encryption strength; for connections that are much harder for attackers to break, set this to 128 bits.

    Caution  

    When you select this check box, clients who are not using the specified encryption strength (including those who aren t using SSL at all) won t be able to connect to your Outlook Web Access server at all. Be sure that you want to do this, or you might have some angry users without e-mail access. If you do enable it, check the IIS HTTP log files to see how many users are failing to connect.

Once you tell IIS to require clients to use SSL, non-SSL clients who try to connect with HTTP alone will get an error 403.4 (Forbidden) message back from IIS; you can test this yourself to verify that everything is working properly.

Automatically Redirecting Non-SSL Requests

Of course, not all of your users will pay attention when you tell them to type https instead of http , so you ll probably get help desk calls or trouble tickets complaining. Fortunately, there s a simple fix: you can automatically guide all users who connect to the base URL of your server to Outlook Web Access with SSL by modifying the error data returned by IIS when a 403.4 error occurs. The steps to do this are fairly simple, as follows :

  1. Create a small ASP file containing the following code excerpt. All this code does is use HTTP redirection to point non-SSL clients to the correct SSL-enabled URL. Save this file in the Inetpub\Wwwroot directory on your Outlook Web Access server, giving it a meaningful name like Https- redirect.asp or something else that makes sense to you.

     <% 
    If Request.ServerVariables("SERVER_PORT")=80 Then
    Dim strSecureURL
    strSecureURL = "https://"
    strSecureURL = strSecureURL & Request.ServerVariables _
    ("SERVER_NAME")
    strSecureURL = strSecureURL & "/exchange"
    Response.Redirect strSecureURL
    End If
    %>
  2. In Internet Information Services (IIS) Manager, open the Properties dialog box for the Exchange virtual directory and click the Custom Errors tab.

  3. Select the list entry for 403.4, and then click Edit Properties. The Error Mapping Properties dialog box opens (see Figure 14-5).

  4. Change the entry in the Message Type drop-down list to URL, then type the relative path to the file you created in step 1 (for example, /https-redirect.asp , or whatever you called it).

  5. Stop and restart the IIS services (the easiest way to do this is to use the Restart button in the Services snap-in). Beware: when you stop the IIS service, you ll stop Exchange as well. Don t do this in the middle of the workday .

    click to expand
    Figure 14-5: The IIS Error Mapping Properties dialog box lets you provide customized messages for specific errors.

Load Balancing SSL Traffic with Outlook Web Access

One advantage to the FE/BE architecture is that FEs can be relatively simple, inexpensive machines. After all, they don t normally store any data, so all they need is a decent CPU and adequate RAM; there is no need for expensive storage hardware. Another related advantage is that the FEs in an Exchange organization don t store any user data, so they re interchangeable; if one fails, you can replace it with another.

This degree of interchangeability has given rise to another nifty capability: you can easily perform load balancing across multiple FE servers. This allows you to transparently distribute an arbitrary number of incoming requests across all your FEs; your users don t have to know, or care, which specific machine they re talking to. Exactly how you configure the load balancing depends on which solution you use. Windows 2000 Server and Windows Server 2003 include the Windows Load Balancing Service, which you can use with Outlook Web Access by following the instructions in the excellent Microsoft Exchange 2000 Server Front-End and Back- End Topology white paper (see the Additional Reading section at the end of the chapter); even though the white paper is written for Windows 2000 Server and Exchange 2000 Server, the same principles apply to Windows Server 2003 and Exchange Server 2003. Other solutions involve the use of dedicated load-balancing devices, like F5 Networks BigIP or Cisco s CSS (Content Services Switch) devices. Many of these load balancers have an additional advantage: they can decrypt large volumes of SSL traffic without hurting the FE servers performance. Even if you don t need the additional performance of a dedicated hardware solution, the advantages offered by an FE processor like ISA Server might make the idea of an SSL endpoint attractive.

Tip  

Normally I tell people to turn off the Windows 2000 License Logging Service. However, you must ensure that it s enabled on your FE servers; when the service is stopped , IIS allows a maximum of 10 simultaneous SSL connections.

As always, though, there s a catch to these advantages: the BE has to generate URLs in the content it creates for the client. These URLs have to change, depending on whether or not SSL was used for the client connection ”the protocol specifier has to be https and not http. Accordingly, the BE needs to know when SSL was used on an incoming connection. This is accomplished by the inclusion of a custom HTTP header, FRONT-END-HTTPS: on. In normal operation, the FE adds this header on its own. However, if you re using a hardware load balancer that can also handle SSL, you ll have to make sure that it includes this header. There are three separate ways to accomplish this, depending on whether you re using FBA:

  • If you re using FBA, you need to add a new key ( HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA\SSLOffloaded ) and give it a value of 1. That tells the ISAPI filter to add the appropriate header.

  • If you re not using FBA, Knowledge Base article 327800 describes an ISAPI filter, ExFeHttpsOnFilter.dll, that adds the necessary header.

  • The SSL accelerator you re using might have a specific method for adding custom headers to particular traffic types; if you don t want to use either of the preceding methods , see the documentation for whatever type of SSL proxy device you re using.

start sidebar
Accelerating SSL

SSL is a CPU- intensive protocol; a great amount of processing is required when new sessions are established. Additionally, there is a minimal amount of processing overhead with every packet. For servers that receive many new connections in a short amount of time, that can really add up. For servers with relatively small user loads, you can probably get by with no acceleration, although you should monitor the server s CPU usage to make sure that the CPU doesn t become a bottleneck.

For more heavily loaded servers, you have three choices: spend the money to buy an SSL accelerator, like those sold by Hewlett-Packard, Rainbow, or nCipher; upgrade the CPU in your server; or add servers to your load- balanced FE server farm. SSL accelerator cards contain cryptographic coprocessors that can encrypt, decrypt, sign, and verify data without imposing a load on the host CPU, along with CryptoAPI drivers that allow CryptoAPI- aware software to automatically offload their crypto operations.

The break point between these two choices will largely depend on the number of simultaneous SSL handshakes your server needs to provide. A typical FE server can generally handle around 100 SSL handshakes per second; beyond that point, it s time to consider upgrading. Adding more CPU power adds scalability for other functions too, like IMAP and POP proxying and SMTP bridgeheading. Adding an SSL accelerator does nothing except speed up SSL handshakes.

Hardware accelerators are fairly inexpensive compared to the cost of a new server, so using them for small numbers of servers that you ve already maxed out on CPU might make sense. However, for larger numbers of servers (as in an Internet service provider [ISP], ASP, or hosting environment), the incremental cost of adding more accelerators mounts, because each accelerator has to have its own SSL certificate and private key, and that certificate must be installed and renewed (not to mention purchased, if you re using a third-party commercial certificate authority). The private key must also be assiduously protected so that no one steals it. For more than a dozen or so servers, it might be more attractive to buy a separate SSL proxy, whether a hardware device like a BigIP or a software proxy like the Microsoft ISA Server. As long as the solution you choose can keep up with your traffic volume and pass the FRONT-END-HTTPS: on header, you ll be in good shape.

end sidebar
 



Secure Messaging with Microsoft Exchange Server 2003
Secure Messaging with MicrosoftВ® Exchange Server 2003 (Pro-Other)
ISBN: 0735619905
EAN: 2147483647
Year: 2004
Pages: 189

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net