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, Microsoft’s own 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 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 Services Manager snap-in to open the Properties dialog box for the Default Web Site object. In 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\Owaasp 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 Services 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, then click Edit Properties. The Error Mapping Properties dialog box opens (see Figure 14-3).

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

  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, /owaasp/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 net stop iisadmin /y command, followed by the net start pop3svc command.). Beware: when you stop the IIS service, you’ll stop Exchange as well. Don’t do this in the middle of the workday.

Enabling Password Changes Through Outlook Web Access

Now that you’ve enabled (or forced) the use of SSL for your Outlook Web Access users, you can safely turn on password changing so that remote users can change their account passwords from within Outlook Web Access. This is invaluable for users who travel frequently or who aren’t physically located near your network.

start sidebar
More Security for Password Changes

IIS 4 and later provided a package called IISADMPWD for changing Windows passwords from a Web page. By default, this package is turned off, which is why you have to take the steps listed next. However, before you do anything, you should understand the differences between the default IISADMPWD that ships with Windows 2000 Service Pack 3 and earlier and the more secure version included with Windows 2000 Service Pack 4 and later.

The original IISADMPWD functionality was implemented as a set of .htr files. The problem with these files is that .htr files are executed by an ISAPI extension that runs in the LocalSystem security context. Compromising this extension could give an attacker full administrative privileges on the local machine. Microsoft has been working to reduce the number of cases in which .htr files are necessary, so they have revamped the way IISADMPWD works by reimplementing it as a set of ASP files.

If you’ve installed Windows 2000 Service Pack 4 or later, then you’re in good shape; the remapping and reinstallation happens automatically. If you haven’t installed Service Pack 4, you should download the revised IISADMPWD package from the Microsoft download center (http://download.microsoft.com/download/iis50/Update/1.0/Win98MeXP/EN-US/iisadmpwd.exe), extract its contents, and install them in the IISADMPWD directory (%Windir%\System32\Inetsrv\Iisadmpwd).

Note that if you’re using the .htr version of IISADMPWD, it stops working after you run IIS Lockdown. By default, IIS Lockdown unmaps the .htr extension, so clients who attempt to use the password change pages get a 404 error. If you’re going to allow users to change their passwords through Outlook Web Access, you’ll need to remap .htr as a supported extension. The simplest way to do this is to rerun IIS Lockdown twice: the first run uninstalls it, and the second reinstalls it. During the reinstallation, you can tell IIS Lockdown to enable .htr files for you. However, it’s a much better idea to download and install the new version of IISADMPWD. See Microsoft Knowledge Base article 331834 for more details.

end sidebar

The basic process is straightforward; you have to create a new virtual directory in IIS, then flip some metabase flags. Here’s what to do:

  1. Launch the Internet Services Manager snap-in, then right-click the Default Web Site object on your Outlook Web Access server, navigate through the New menu, and select Virtual Directory. This launches the Virtual Directory Creation Wizard.

  2. At the welcome screen, click Next. When the wizard asks you to provide an alias for the new virtual directory. Type IISADMPWD, then click Next.

  3. The directory path you must specify is %Systemroot%\System32\Inetsvr\Iisadmpwd because this virtual directory is just going to expose some code that ships with IIS; Microsoft leaves the feature turned off by default because they don’t want you to use it without SSL.

  4. In the Access Permissions page of the wizard, make sure that only the Read and Run Scripts check boxes are set. This is critical, because giving people the right to write into that directory might make it possible for them to replace the password changing scripts with their own ones, and that would be bad.

  5. Click Next, then click Finish to create the virtual directory and close the wizard.

  6. Turn on anonymous access for the virtual directory you just created. You have to do this because if you don’t, users whose passwords have expired—the ones who most need to change their passwords—won’t be able to. Why? Once their passwords have expired, they can’t log on. To make this change, open the Properties dialog box for the IISADMPWD virtual directory, click the Directory Security tab, click Edit Within Anonymous Access And Authentication Control, and make sure that the Anonymous Access check box is selected.

  7. Reset the PasswordChangeFlags flag in the metabase to zero. The adsutil script in \Inetpub\Adminscripts\ is the best tool to use; this command line makes the change:

    cscript.exe adsutil.vbs set w3svc/passwordchangeflags 0

    You can set PasswordChangeFlags to other values, too. Zero enables password changes with SSL only. A value of 1 allows passwords to be changed without SSL, but that’s not a good idea. A value of 2 disables password changes altogether, and a value of 4 disables password changes and the notification message Outlook Web Access normally displays when your password is about to expire.

Tip

If you don’t want your clients to even see the Change Password button, you can hide it altogether. Add a new registry key named OWA to the existing HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWEB registry key, then add a new REG_DWORD value named DisablePassword to the OWA key. When DisablePassword is set to 1, the button does not appear; setting the value to 0, or removing the key, allows it to appear normally. Note that you must stop and restart the Exchange information store and the IIS w3svc, along with all of their dependent services, before this change takes effect.

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 all of the FEs in an Exchange organization are 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 Advanced Server includes 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). 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.

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 (exact instructions for doing so depend on the 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 two choices: spend the money to buy an SSL accelerator, like those sold by Hewlett-Packard, Rainbow, or RSA Data Security, or spend the money to upgrade the CPU in your server. 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 CA). 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 Microsoft’s 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

Controlling Content Caching

A little knowledge is a dangerous thing. Most Web users have become at least dimly aware that browsers can cache things, and so administrators are sometimes concerned that Outlook Web Access will cause client systems to cache sensitive materials or documents. It’s true that browsers cache things, but Outlook Web Access’s designers have taken some pains to limit what is cached by default.

First, the simplest consideration is the form pages themselves (like the new message form you see when composing a draft message). These forms are cached purely for performance reasons. That’s acceptable, because there’s nothing sensitive about the appearance or function of the widgets in the message forms themselves. When you open a mail message to read or reply to it, Outlook Web Access sends an HTTP header instructing the browser not to cache it. The message remains in the browser’s memory until you close the window it’s in, at which point it’s flushed. So far, so good.

Attachments pose a somewhat more difficult problem. The good news is that, unlike Outlook, the attachment isn’t ever downloaded to the client unless the user requests it. If the user doesn’t click on the attachment link, the attachment isn’t sent to the client browser. If the user does request the attachment, there are a number of possibilities:

  • If the user right-clicks the link and chooses Save Target As (or its equivalent in browsers other than Internet Explorer), the attachment is downloaded to the user’s specified location. Outlook Web Access has no way to prevent or control this. If you don’t want your users leaving sensitive documents on public machines, teach them not to do this.

  • If the user clicks on the link, the browser normally opens a dialog box offering the choice of opening or saving the document. If the user chooses to save the document, it’s out of Outlook Web Access’s control.

  • If the user chooses to open the document, Outlook Web Access sends an expiration header that tells the browser that the requested document expired the previous day. This prevents the browser from caching the file permanently, but it might still have to write the attachment to disk so it can be opened by a helper application. The browser eventually purges its cache to delete expired objects, but there’s no guarantee that this will happen immediately.

In all three of these cases, it’s possible for a sensitive attachment to end up on the local disk of an unprotected machine. The only way to prevent this is to train users not to open sensitive attachments on untrusted machines. Even though Outlook Web Access is sending proper headers to tell the browser what to cache, and even though all browsers shipped since 1998 or so honor these headers, it’s still possible for users to end up saving that salary summary or secret product plan to an airport kiosk, unless you teach them not to.

If you want a technical solution, you can use IIS Lockdown (or, more precisely, URLScan) to block access to certain types of attachments. This works because the URL for the attachment contains the name of the attachment file; if you set up URLScan to block the file types you’re worried about, it uses a 404 error message when users try to download those items. Note that this hampers users’ ability to get work done, so don’t do it casually.




Secure Messaging with Microsoft Exchange Server 2000
Secure Messaging with Microsoft Exchange Server 2000
ISBN: 735618763
EAN: N/A
Year: 2003
Pages: 169

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