ISA Server 2004 UNLEASHED [Electronic resources] نسخه متنی

Figure 12.16. Explaining OWA publishing with ISA Server 2004.

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:Enabling Secure Sockets Layer (SSL) Support for Exchange Outlook Web Access" must be followed first to create a certificate for OWA.

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.

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:

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:Chapter 13 on OMA, ActiveSync, and RPC over HTTP for more info on how to do this.

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.

Checking this box, clicking OK, and then saving changes to ISA forces all connections to use the highly secured 128-bit SSL traffic.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.

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="
<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 (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

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:

NOTE

The redirect 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 Chapter 7.

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

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.

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:

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:

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:

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: