Improving Outlook Web Access Client Security | Secure Messaging with MicrosoftВ® Exchange Server 2003 (Pro-Other)

Of course, improving the server s security is only part of the requirement for securing Outlook Web Access. You can also take some steps to improve the security of the OWA client experience. Of course, because OWA is a server-heavy application, you don t actually configure these settings on the client, but rather on the server.

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.

In Exchange 2000 Server, you had to take several steps to enable password changes through Outlook Web Access, which was off by default. It s still off in Exchange Server 2003, but what you have to do to enable it depends on what operating system you re using: if you re using Windows Server 2003, you only need to flip a registry value from 1 to 0, but if you re running on Windows 2000 Server, you have a bit more work to do.

Enabling Password Changes on Windows 2000

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

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.
On the Welcome page, click Next . When the wizard asks you to provide an alias for the new virtual directory, type IISADMPWD , then click Next.
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.
On the Access Permissions page of the wizard, make sure that only the Read and Run Scripts check boxes are selected. 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.
Click Next, and click Finish to create the virtual directory and close the wizard.
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.
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.

More Security for Windows 2000 Server Password Changes

IIS 4 and later versions 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 Server Service Pack 3 and earlier and the more secure version included with Windows 2000 Server 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 Server 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.

Enabling Password Changes on Windows Server 2003

Windows Server 2003 ships with IIS 6.0, which doesn t require all the procedures just described. All you have to do is flip the value of HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeWEB\OWA\DisablePassword from 1, which disables password changes, to 0, which allows them. Once you ve done so, you ll need to stop and restart both the information store and all of the IIS services; it might be easier just to reboot the server.

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.

Controlling Attachment Access

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 measures 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 is in, at which point it is flushed. So far, so good. (OWA always tags dynamic data with a do-not-cache flag.)

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 from an Outlook Web Access server, 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. If you don t want your users leaving sensitive documents on public machines, teach them not to do this.
If the user clicks 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 best way to prevent this is to train users not to open sensitive attachments on untrusted machines. Why do I say best ? Because it works on all versions of Outlook Web Access. However, it s not fair to put the entire burden on the user. Accordingly, Microsoft has added some attachment blocking features to Outlook Web Access 2003.

Blocking Specified File Types

In Chapter 13, Securing Outlook, I described how Outlook provides administrators with a way to restrict access to attachments based on their file type. Besides the wholesale blocking described in the next section, Outlook Web Access 2003 allows you to block individual file types in exactly the same way that Outlook does. In fact, the mechanism works so much like Outlook that there s no point in describing it again in detail here, except to point out that it s controlled by the Level1FileTypes and Level2FileTypes values (both REG_SZs) beneath HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA. By tweaking these values, you can control which file types Outlook Web Access users can access; in most cases, you ll probably want that list to match the list of blocked file types in Outlook to consistently block potentially dangerous content.

Restricting Attachment Access

Sometimes you might want to prevent all access to attachments. For example, if you re worried about leakage of confidential data, one good way to help prevent it is to keep the confidential material off of random machines by disallowing Outlook Web Access users from opening it. You can do this by creating a new value named DisableAttachments beneath the HKLM\System\CurrentcontrolSet\Services\MSExchangeWeb\OWA registry key. This value accepts three possible settings:

0 allows access to all attachments; this is the default behavior you get when this key doesn t exist.
1 blocks access to all attachments from within Outlook Web Access; users can t open or save attachments at all.
2 blocks attachment access for sessions that originate at an FE, but allows it for users who connect directly to BEs. This allows you to grant attachment access to users on your corporate network while blocking attachments for users on the Internet.

As an additional option, you can choose to allow access from some FEs but not others; to do this, you have to set DisableAttachments to 2, then create a new REG_SZ value SYSTEM\CurrentControlSet\Services\MSExchangeWEB registry key, then add a new REG_DWORD value named AcceptedAttachmentFrontEnds to the OWA key beneath the OWA subkey . Its contents should be a comma-delimited list of the host names of the FEs from which you want users to have attachment access.

Tip	Attachment file type blocking takes precedence; even if you set DisableAttachments to 0, your users can t get files of types you ve blocked.

Blocking Freedocs

Many users have discovered that public folders make a dandy holding cell for documents. Not documents attached to messages, mind you ”just plain old documents, saved into a public folder in the same way you d save a document to a SharePoint site or a file server. The problem with freedocs is that they are directly accessible through a URL, meaning that a semiclever attacker with legitimate access could plant a freedoc with malicious code or macros, then have it attack other machines when opened. To prevent this, Exchange Server 2003 disallows direct freedoc access by default. You can set the EnableFreeDocs registry value on the BE to any of the following values:

A value of 0 blocks freedoc access from Outlook Web Access. Documents are still accessible from Microsoft Office and other programs that support WebDAV access to public folders, though.
Setting it to 1 allows freedoc access from Outlook Web Access BE servers only.
A setting of 2 allows access to freedocs from BEs or from FEs whose host headers appear in the AcceptedAttachmentFrontEnds value.
Set EnableFreeDocs to 3 to allow access to freedocs from anywhere at any time.

Providing S/MIME

The S/MIME capability of Outlook Web Access is pretty impressive when you think about it: users who have local copies of their certificates and private keys can send and receive signed and encrypted e-mail without storing their certificates on a central server. The Outlook Web Access server is responsible for checking the status of certificates needed to verify signatures or encrypt outgoing messages; recall that signature verification and encryption can both be done with only public certificates, so these operations can be performed on the server. For signing and decryption, obviously the client needs a local copy of the certificate and private key, which is where the client-side S/MIME ActiveX control comes in.

Yes, that s right: all of the client-side S/MIME functionality in Outlook Web Access requires the user to download and install an ActiveX control on the client, and the client has to be running Windows 2000 Professional or later and Internet Explorer 6.0 or later. That, of course, means that your users probably won t be able to use S/MIME everywhere they go, but that s fine ”they can t use the client-side functionality unless they have their certificates with them anyway! In most cases, that means that the client will need a smart card or token with certificates (that, in turn, implies the existence of a reader for the card or token, drivers for the host operating system, and so forth). The client S/MIME control is perfectly happy to use any certificate that can be made visible to the Windows certificate store, though, so certificates you ve exported to .pfx files work just fine as long as you remember to import them to the store.

Each client has to have the S/MIME control installed. Individual users can easily do this by logging in to Outlook Web Access, clicking Options, and scrolling down to the E-Mail Security section, where clicking Download downloads the control to the user s machine. You can also push the control using Group Policy, Systems Management Server, or other distribution tools. Once the S/MIME control is installed, users can use Outlook Web Access to generate signed and encrypted messages using the familiar Outlook-like toolbar icons for signing and encrypting messages.