Securing Exchange Outlook Web Access with ISA Server 2004

As previously mentioned, OWA is one of the most commonly secured services that ISA Servers protect. This stems from the critical need to provide remote email services while at the same time securing that access. The success of ISA deployments in this fashion give tribute to the tight integration Microsoft built between its ISA product and Exchange product.

An ISA Server used to secure an OWA implementation can be deployed in multiple scenarios, such as an Edge firewall, an inline firewall, or a dedicated reverse-proxy server. In all these scenarios, ISA secures OWA traffic by "pretending" to be the OWA server itself, scanning the traffic that is destined for OWA for exploits, and then repackaging that traffic and sending it on, such as what is illustrated in Figure 12.16.

Figure 12.16. Explaining OWA publishing with ISA Server 2004.

NOTE

There are a few differences in setup and configuration of a deployment scenario where ISA is in the DMZ of an existing firewall. These scenarios are discussed in more detail in Chapter 7.

ISA performs this type of OWA securing through a mail publishing rule, which automatically sets up and configures a Listener on the ISA Server. A Listener is an ISA component that listens to a specific IP address and port combination for traffic, and processes that traffic for the requesting client as if it were the actual server itself. For example, an OWA Listener on an ISA Server would respond to OWA requests made to it by scanning them for exploits and then repackaging them and forwarding them on to the OWA server itself. Using listeners, the client cannot tell the difference between the ISA Server and the OWA server itself.

ISA Server is also one of the few products that has the capability to secure web traffic with SSL encryption from end to end. It does this by using the OWA server's own certificate to re-encrypt the traffic before sending it on its way. This also allows for the "black box" of SSL traffic to be examined for exploits and viruses at the Application layer, and then re-encrypted to reduce the chance of unauthorized viewing of OWA traffic. Without the capability to scan this SSL traffic, exploits bound for an OWA server could simply hide themselves in the encrypted traffic and pass right through traditional firewalls.

Exporting and Importing the OWA Certificate to the ISA Server

For ISA to be able to decrypt the SSL traffic bound for the Exchange OWA server, ISA needs to have a copy of the certificate used on the OWA server. This certificate is used by ISA to decode the SSL packets, inspect them, and then re-encrypt them and send them on to the OWA server itself. For this certificate to be installed on the ISA server, it must first be exported from the OWA server as follows:

NOTE

The steps in the earlier section titled "Enabling Secure Sockets Layer (SSL) Support for Exchange Outlook Web Access" must be followed first to create a certificate for OWA.

1.	From the OWA Server (not the ISA Server) open IIS Manager (Start, All Programs, Administrative Tools, Internet Information Services [IIS] Manager).
2.	Navigate to Internet Information Services, SERVERNAME (local computer), Web Sites.
3.	Right-click on the OWA Virtual Server (typically named Default Web Site) and choose Properties.
4.	Choose the Directory Security tab.
5.	Click View Certificate.
6.	Click the Details tab.
7.	Click Copy to File.
8.	At the wizard, click Next to begin the export process.
9.	Select Yes, Export the Private Key as shown in Figure 12.17, and click Next to continue. Figure 12.17. Exporting the SSL private key.
10.	Select to include all certificates in the certification path and also select to enable strong protection and click Next to continue.
11.	Type and confirm a password and click Next to continue.
12.	Enter a file location and name for the file and click Next.
13.	Click Finish.

After the .pfx file has been exported from the OWA server, it can then be imported to the ISA Server via the following procedure:

CAUTION

It is important to securely transmit this .pfx file to the ISA server and to maintain high security over its location. The certificate's security could be compromised if it were to fall into the wrong hands.

1.	From the ISA Server, open the MMC console (Start, Run, mmc.exe, OK).
2.	Click File, Add/Remove Snap-in.
3.	Click the Add button.
4.	From the list shown in Figure 12.18, choose the Certificates snap-in and click Add. Figure 12.18. Customizing an MMC Certificates snap-in console for import of the OWA certificate.
5.	Choose Computer Account from the list when asked what certificates the snap-in will manage and click Next to continue.
6.	From the subsequent list in the Select Computer dialog box, choose Local Computer (the Computer This Console Is Running On) and click Finish.
7.	Click Close and OK.

After the custom MMC console has been created, the certificate that was exported from the OWA server can be imported directly from the console via the following procedure:

1.	From the MMC Console root, navigate to Certificates (Local Computer), Personal.
2.	Right-click the Personal folder and choose All Tasks, Import.
3.	At the wizard welcome screen, click Next to continue.
4.	Browse for and locate the .pfx file that was exported from the OWA server. The location can also be typed into the file name field. Click Next when located.
5.	Enter the password that was created when the certificate was exported, as illustrated in Figure 12.19. Do not check to mark the key as exportable. Click Next to continue. Figure 12.19. Installing the OWA Certificate on the ISA Server.
6.	Choose Automatically select the certificate store based on the type of certificate, and click Next to continue.
7.	Click Finish to complete the import.

After it is in the certificates store of the ISA Server, the OWA SSL certificate can be used as part of publishing rules.

NOTE

If a rule that makes use of a specific SSL certificate is exported from an ISA Server, either for backup purposes or to transfer it to another ISA server, then the certificate must also be saved and imported to the destination server, or that particular rule will be broken.

Creating an Outlook Web Access Publishing Rule

After the OWA SSL has been installed onto the ISA Server, the actual ISA mail publishing rule can be generated to secure OWA via the following procedure:

NOTE

The procedure outlined here illustrates an ISA OWA publishing rule that uses forms-based authentication (FBA) for the site, which allows for a landing page to be generated on the ISA Server to pre-authenticate user connections to Exchange. This forms-based authentication page can be set only on ISA, and must be turned off on the Exchange server itself to work properly. Therefore, this particular rule does not configure the ancillary services of OMA, ActiveSync, and RPC over HTTP. If FBA is not used, these services can be installed as part of the same rule. See Chapter 13 on OMA, ActiveSync, and RPC over HTTP for more info on how to do this.

1.	From the ISA Management Console, click once on the Firewall Policy node from the console tree.
2.	From the Tasks tab in the task pane, click on the link titled Publish a Mail Server.
3.	Enter a name for the rule and click Next to continue.
4.	From the Access Type dialog box, select Web client access (OWA), Outlook Mobile Access, Exchange Server ActiveSync and click Next to continue.
5.	From the Select Services dialog box, ensure that the boxes for Outlook Web Access and Enable High Bit Characters Used by Non-English Character Sets are checked (OMA and ActiveSync should not be checked because they need to be secured with a different rule if forms-based authentication is used) and click Next to continue.
6.	From the Bridging Mode dialog box, shown in Figure 12.20, select to create a secure connection to clients and mail server. This ensures that the communications are encrypted from end to end. Click Next to continue. Figure 12.20. Selecting the OWA publishing rule bridging mode.
7.	Enter the Fully Qualified Domain Name (FQDN) of the OWA server. This should match the external name referenced by the client (for example, mail.companyabc.com). Click Next to continue. CAUTION For an SSL-based OWA rule to work, the FQDN entered in this dialog box must exactly match what the clients will be entering into their web browsers. If it does not match, the host header for the SSL traffic from the ISA server to the Exchange OWA server changes, which causes an upstream chaining error when the site is accessed. It is also very important that the ISA Server is able to resolve the FQDN to the internal OWA server, and not to an outside interface. This may involve creating a hosts file to redirect the ISA server to the proper address. This type of scenario is often the case when the ISA Server is configured in the DMZ of an existing firewall, which is covered in more detail in Chapter 7.
8.	Under the Public Name Details dialog box, select to Accept Request for This Domain Name (Type Below) and enter the FQDN of the server into the Public Name field (for example, mail.companyabc.com). Click Next to continue.
9.	Under the Web Listener dialog box, click the New button, which invokes the New Web Listener Wizard.
10.	In the welcome dialog box, enter a descriptive name for the web listener (for example, OWA SSL Listener with FBA) and click Next.
11.	Under the IP Addresses dialog box, check the box to listen from the External network, and click Next to continue.
12.	At the Port Specification dialog box, uncheck Enable HTTP, then check Enable SSL.
13.	Click on the Select button to locate the certificate installed in the previous steps, select it from the list displayed, and click OK to save the settings.
14.	Click Next to continue.
15.	Click Finish to complete the Listener Wizard.
16.	While still on the Select Web Listener dialog box, with the new Listener selected, click the Edit button.
17.	Select the Preferences tab.
18.	Under the Preferences tab, select the Authentication button, as shown in Figure 12.21. Figure 12.21. Configuring the OWA SSL Listener.
19.	Uncheck Integrated from the list of allowed authentication methods.
20.	Click OK to acknowledge the warning about requests being denied with no methods of authentication in place.
21.	Check the box for OWA Forms-Based authentication.
22.	Click the Configure button to configure FBA.
23.	Enter OWA FBA Settings on the dialog box shown in Figure 12.22. The settings chosen should reflect the particular security requirements of the organization. Click OK when complete. Figure 12.22. Configuring forms-based authentication.
24.	Click OK and OK again to save the changes to the Listener, and then click Next to continue.
25.	Under the User Sets dialog box, accept the default of All Users, and click Next to continue.
26.	Click Finish to complete the wizard.
27.	Click the Apply button at the top of the details pane.
28.	Click OK to acknowledge that the changes are complete.

At this point, the ISA Server is set up to reverse proxy the OWA traffic and scan it for Application-layer exploits. This rule applies only to HTTPS traffic, however, so additional rules need to be created if HTTP traffic should be automatically redirected to HTTPS traffic.

One final configuration step for many environments would be to force the SSL traffic to use 128-bit encryption, as opposed to as low as 40-bit (the default). Making this change also makes it possible to take a good look at the options and features of the rule itself. Double-click on the newly created rule in the Details pane, and look through the tabs to see the options created in the rule. The particular option for forcing 128-bit SSL is located on the Traffic tab, as shown in Figure 12.23.

Figure 12.23. Forcing 128-bit encryption.

Checking this box, clicking OK, and then saving changes to ISA forces all connections to use the highly secured 128-bit SSL traffic.

CAUTION

It is important not to be confused by some of the options listed under the tabs of the individual publishing rule itself. Some of the options may seem to be necessary, but end up breaking the rule itself. If testing a different scenario, be sure to export it out to an XML file for backup purposes before making changes. ISA publishing rules need to be set up "just so," and minor changes to the rules can break the rules, so it is useful to save the specific rule so that it can be restored in the event of a problem. See Chapter 18, "Backing Up, Restoring, and Recovering an ISA Server 2004 Environment," for step-by step instructions on exporting individual rules.

Redirecting HTTP OWA Traffic to HTTPS traffic

Securing SSL traffic through OWA is a good start, but many organizations require some HTTP traffic to be handled, mainly to provide external clients with ease of use by automatically redirecting their requests for an http:// URL to one that starts with https://. For example, a user on the Internet typically types in the URL of the OWA web page simply as mail.companyabc.com. The problem with this is that the browser assumes that it is regular, unencrypted HTTP traffic and attaches an http:// prefix, forcing the traffic to run as HTTP traffic.

When configured with the rule described in the previous section on configuring the OWA rule in ISA, ISA would refuse this HTTP traffic because it has a very strict rule that specifies that only HTTPS traffic should be used. This would be the case even if the ASP file that redirects traffic described in the previous section were used. This creates somewhat of a dilemma: The need to provide for ease of use clashes with the need to secure the environment.

Many organizations have found it useful to perform the automatic redirection on the OWA server itself, primarily through a custom 403.4 error ASP message, as previously described. This technique is a useful mechanism for performing a simple type of redirect on the virtual server of OWA itself.

The only downside to this type of redirect is that it requires unauthenticated HTTP traffic to hit the OWA server. This occurs either by adding HTTP functionality to the listener or creating a new listener and associated rule to allow the traffic through. This is not too large of a concern because ISA scans the traffic for exploits and the OWA server automatically rejects the HTTP traffic and forces the redirection. However, many security administrators have looked for ways to further secure this scenario, particularly if ISA is deployed in the DMZ of an existing firewall, and the preference is to keep all unauthenticated traffic to the DMZ itself.

Fortunately, there is a relatively straightforward way to accomplish both creating a secure OWA environment and providing for automatic redirection of the HTTP traffic, without requiring any unauthenticated traffic to pass through into the internal network. In this scenario, a special rule is configured on the ISA Server to redirect any HTTP traffic sent to the OWA server to a single HTML file on a web server in an isolated network, such as a DMZ network, such as what is illustrated in Figure 12.24.

Figure 12.24. Automatically redirecting HTTP OWA traffic to HTTPS.

An existing web server, be it Windows IIS, Linux Apache, or any other standard HTML 1.2compliant web server, can be used for this, and the only requirement is that a virtual directory should be created to house the simple, three-line HTML file that performs the redirection.

NOTE

Although it may seem as if ISA would be a likely candidate to do the redirection itself, there is no built-in mechanism to perform this. The web component of IIS should never be installed on an ISA server itself. This procedure requires that some web servers be made available.

The process to implement this solution requires two steps. In the first step, the HTML redirect page is created on the web server in the DMZ. Secondly, the ISA rule is created to redirect the traffic.

Setting Up the HTTP Redirect File on the Web Server

For the first step, a separate server with web services enabled must be identified and the HTML web file must be placed into a virtual directory on that server.

The text of the HTML web file should be as follows:

 <html> <meta HTTP-EQUIV="REFRESH" content="0; url=https://mail.companyabc.com/exchange" <html/> 

Note that the mail.companyabc.com portion of the file should be replaced with the publicly accessible name of the OWA website. The procedure for placing this file on the web server in question varies based on the type and version of web server being used, but it essentially involves saving the lines of HTML code into a file named redirect.htm (or any other descriptive name) and placing it into a virtual directory such as /isa on the web server. For example, the following URL represents one particular web structure for accessing the file:

http://www.companyabc.com/isa/redirect.htm

The procedure for installing this file varies depending on the version of web services software installed. For Internet Information Services v6, the steps would be as follows:

1.	From the web server in the DMZ, create a directory named isa anywhere on the server (for example, C:\isa).
2.	Create the redirect.htm file in Notepad, using the example given, and save that file in the isa folder, making sure that it is saved as an .htm file and not a .txt file.
3.	Open IIS Manager (Start, All Programs, Administrative Tools, Internet Information Services [IIS] Manager) and navigate to SERVERNAME, Web Sites.
4.	Right-click on the virtual server to which the virtual directory will be added (for example, the WWW site for the organization) and choose New, Virtual Directory.
5.	Click Next at the welcome screen.
6.	Under Alias, enter isa and click Next.
7.	On the Web Site Content Directory dialog box, enter the patch of the directory created earlier (for example, C:\isa).
8.	Under the Virtual Directory Access Permissions dialog box, select to allow only Read (uncheck Run scripts and leave the others blank), then click Next to continue.

NOTE

The redirect.htm file does not need to be directly accessible from the Internet; it needs to be accessible only from the ISA server itself. In this scenario, ISA is configured to reverse proxy the site.

Creating the ISA Server HTTP Redirect Rule

The second step in the redirection process is to create the ISA rule that redirects traffic sent to http://mail.companyabc.com to http://www.companyabc.com/isa/redirect.htm, which in turn redirects the user to https://mail.companyabc.com/exchange.

NOTE

The procedure outlined here also applies to a unihomed ISA configuration, where the ISA server is deployed into the DMZ of an existing firewall. For more information on this scenario, reference Chapter 7.

To create the ISA redirect rule, perform the following steps:

1.	From the ISA Console, select the Firewall Policy node from the console tree.
2.	Under the Tasks tab of the Tasks pane, click the link for Publish a Web Server.
3.	For the web publishing rule name, enter a descriptive name, such as OWA HTTP Redirect, and click Next to continue.
4.	Under rule action, select Allow and click Next.
5.	Under the Define Website to Publish dialog box, shown in Figure 12.25, enter the name or IP address of the server to which the redirect file was saved, keeping in mind that the IP or name entered must be accessible from ISA itself, not necessarily to users from the Internet. Enter isa/redirect.htm as the path and click Next to continue. Figure 12.25. Defining the location of the HTTP redirect file.
6.	Under the Public Name Details dialog box, select to accept requests from the domain name of the OWA server, and change the path to blank, as shown in Figure 12.26. Click Next to continue. Figure 12.26. Configuring the HTTP Redirect rule.
7.	Under the Select Web Listener dialog box, click New.
8.	Enter a descriptive name for the Web Listener, such as HTTP Redirect Listener, and click Next.
9.	Select to listen for requests from the external website by checking the box from the list and click Next to continue.
10.	Under the Port Specification dialog box, accept the default of HTTP Traffic Only and click Next.
11.	Click Finish to create the Listener.
12.	Click Next to continue.
13.	Accept the default of All Users under User Sets, and click Next.
14.	Click Finish to finalize the settings.
15.	Click Apply at the top of the Details pane.
16.	Click OK to acknowledge that the changes were saved to ISA.

When used in combination with the HTTPS OWA Mail Publishing rule, the HTTP Redirect rule can be a useful way to provide ease of use while maintaining a high level of security.

Customizing Forms-Based Authentication

The forms-based authentication (FBA) mechanism allows for a flexible approach to OWA authentication and keeps unauthenticated packets away from the OWA server. Many organizations require that custom OWA landing pages be created, however, so that they can incorporate special wording, or simply to rename the "domain\username" field in the form to simply "username." Fortunately, ISA Server 2004 makes customization of key wording in the OWA FBA page straightforward and uncomplicated.

The text in the FBA page is pulled from a single text file, located in the following location on the ISA server:

 \Program Files\Microsoft ISA Server\CookieAuthTemplates\strings.txt 

This file, shown in Figure 12.27, is a simple text file that can be modified to match an organization's needs. After it is modified, the firewall service needs to be restarted so that the changes can be viewed.

Figure 12.27. Editing the strings.txt file to customize FBA.

CAUTION

If the ISA server being modified is placed in production, make sure to warn users or schedule the downtime that will be associated with a firewall service reset. Resetting the service effectively kills all connections traveling through the firewall, including web servers, terminal service sessions, and VPN connections.

Enabling the Change Password Feature in OWA Through an ISA Publishing Rule

By default, Exchange Server 2003 does not display the Change Password button in Outlook Web Access. This option was previously made available by default in Exchange 2000 OWA, so many administrators may be looking to provide for this same functionality.

The Change Password button was removed to provide for a higher degree of default security in Exchange Server 2003, particularly because the Exchange 2000 Change Password feature was highly insecure in its original implementations. Fortunately, however, the Exchange Server 2003 Change Password option in OWA was recoded to operate at a much lower security context, and is subsequently much safer. Despite this fact, however, this functionality must still be enabled, first on the Exchange server, and then on the ISA Server itself.

Enabling the Change Password Feature on the OWA Server

Enabling the Change Password feature on the Exchange OWA server involves a three-step process: creating a virtual directory for the password reset, configuring the virtual directory, and modifying the Exchange server Registry to support the change. To start the process and create the virtual directory, do the following:

1.	From the OWA Server, open IIS Manager (Start, All Programs, Administrative Tools, Internet Information Services [IIS] Manager).
2.	Right-click the OWA Virtual Server (typically named Default Web Site) and choose New, Virtual Directory.
3.	At the welcome dialog box, click Next.
4.	Under Alias, enter iisadmpwd and click Next.
5.	Enter C:\windows\system32\inetsrv\iisadmpwd into the path field, as shown in Figure 12.28 (where C:\ is the system drive) and click Next to continue. Figure 12.28. Creating the IISADMPWD virtual directory.
6.	Check the boxes for Read and Run Scripts permissions and click Next.
7.	Click Finish.

After it is created, the IISADMPWD virtual directory needs to be configured to use the Exchange Application pool, and also be forced to use Basic Authentication with SSL (highly recommended for security reasons). To do so, perform the following steps:

1.	In IIS Manager, under the OWA Virtual Server, right-click the newly created iisadmpwd virtual directory and choose Properties.
2.	Under the Virtual Directory tab, in the Application Settings field, choose ExchangeApplicationPool from the drop-down box labeled Application Pool, as shown in Figure 12.29. Figure 12.29. Modifying the IISADMPWD virtual directory.
3.	Choose the Directory Security tab, and click Edit under Authentication and Access Control.
4.	Uncheck Enable Anonymous Access, and check Basic Authentication.
5.	Click Yes to acknowledge the warning (SSL will be used, so this warning is moot).
6.	Click OK to save the authentication methods changes.
7.	Under Secure Communications, click the Edit button.
8.	Check the boxes for Require Secure Channel (SSL) and Require 128-bit Encryption and click OK twice to save the changes.

After the virtual directory has been created, a Registry change must be made to allow password resets to take place. To do this, perform the following tasks:

1.	Click Start, Run, type in regedit.exe, and click OK.
2.	Navigate to My Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\MSExchangeWEB\OWA.
3.	Look for the DWORD value labeled DisablePassword, as shown in Figure 12.30, double-click on it, enter 0 in the value data field, and click OK. Entering 0 forces changes to be made in SSL, which is highly recommended. Figure 12.30. Changing the Registry to support password resets.
4.	Back in IIS Manager, restart IIS by right-clicking on the server name in IIS Manager and choosing All Tasks, Restart IIS, and then click OK.

Modifying the ISA OWA Publishing Rule to Support the Change Password Feature

After the Change Password feature has been enabled on the OWA server, the existing ISA OWA publishing rule must be modified to support the change. To do this, add the iisadmpwd virtual directory to the rule by using the following procedure:

1.	From the ISA Server, open the ISA Management Console (Start, All Programs, Microsoft ISA Server, ISA Server Management).
2.	Navigate to the Firewall Policy Node in the console tree.
3.	Double-click on the OWA Rule created in the earlier steps (not the redirect rule).
4.	Select the Path tab.
5.	Click Add.
6.	For the path, enter /iisadmpwd/*, as shown in Figure 12.31. Figure 12.31. Allowing change password functionality in an ISA OWA publishing rule.
7.	Click OK, OK, Apply, and OK to save the changes.