Configuring ISA to Redirect OWA Users to the Correct Directories and Protocols (Part 2)

by Thomas Shinder [Published on 28 July 2005 / Last Updated on 28 July 2005]

Part 1 of this two-part series on how to redirect OWA users to the right site and protocol discussed the issues involved with creating redirects for users who enter incorrect URLs or incorrect protocols when accessing the OWA Web site. We also went over the initial configuration steps you can use to perform the redirects. In this, part 2 and final part of the series, we’ll go over the configuration steps from beginning to end and explain the rationale behind the steps. By the time you finish the procedure, users will be able to enter incorrect paths and incorrect protocols and still be redirected to the correct OWA Web site. The end result is fewer Help Desk calls.

If you missed the first part of this article please read, Using ISA to Redirect OWA Users to the Correct Directories and Protocols (Part 1).

Part 1 of this two-part series on how to redirect OWA users to the right site and protocol discussed the issues involved with creating redirects for users who enter incorrect URLs or incorrect protocols when accessing the OWA Web site. We also went over the initial configuration steps you can use to perform the redirects. In this, part 2 and final part of the series, we’ll go over the configuration steps from beginning to end and explain the rationale behind the steps. By the time you finish the procedure, users will be able to enter incorrect paths and incorrect protocols and still be redirected to the correct OWA Web site. The end result is fewer Help Desk calls.

In this article we will discuss the following topics and procedures:

  • Installing the WebDirect software
  • Creating the OWA Web Publishing Rule
  • Creating the Redirect Absent Path to Exchange Web Publishing Rule
  • Creating the Redirect HTTP to HTTPS Web Publishing Rule
  • Testing and analyzing the configuration

Installing the WebDirect Software

Perform the following steps to download and install the WebDirect software:

  1. Open Internet Explorer and go to http://www.collectivesoftware.com/Products/ and download the WebDirect software.
  2. Double click on the WebDirect.msi file to begin the installation
  3. Select the Complete option and click Install.
  4. Click Finish on the Completing the Collective Software WebDirect v1.1.5 Setup Wizard.
  5. Click OK on the dialog box indicating that you should restart the Firewall service to ensure that the WebDirect Web filter installed correctly.
  6. If the ISA firewall console is open, close it and then open it again.
  7. In the ISA firewall console, expand the server name and then click the Monitoring node. Click the Services tab. Right click the Microsoft Firewall service and click Stop. After the service stops, right click it again and click Start.

Creating the OWA Web Publishing Rule

In this example I’ll publish an example OWA Web site that is reachable using the URL https://owa.msfirewall.org/exchange. Our sample network utilizes a well-designed split DNS infrastructure so that users can roam between the corporate network and external locations and always use the same name to access the OWA site.

A split DNS is also a critical component for getting the best results for OMA, ActiveSync, RPC over HTTP, and secure Exchange RPC Publishing. The split DNS infrastructure in this example enables the external host to resolve owa.msfirewall.org to the external IP address on the ISA firewall and internal hosts resolve the name owa.msfirewall.org to the site’s actual IP address on the internal network.

We will also use SSL to SSL bridging; this provides the highest level of security and avoids the significant security pitfalls associated with SSL to HTTP bridging (SSL to HTTP bridging is mentioned only to condemn it). The Web site certificate bound to the OWA Web site has the common/subject name owa.msfirewall.org and that certificate was exported with its public key and installed in the ISA firewall’s machine certificate store.

Perform the following steps to create the OWA Web Publishing Rule:

  1. In the ISA firewall console, expand the server name and click the Firewall Policy node.
  2. Click the Tasks tab in the Task Pane and click the Publish a Mail Server link.
  3. On the Welcome to the New Mail Server Publishing Rule Wizard page, enter OWA in the Mail Server Publishing Rule name text box and click Next.
  4. On the Select Access Type page, select the Web lcent access: Outlook Web Access (OWA), Outlook Mobile Access, Exchange Server ActiveSync option and click Next.
  5. On the Select Services page, put a checkmark in the Outlook Web Access checkbox and click Next.
  6. On the Bridging Mode page, select the Secure connection to clients and mail server option and click Next.
  7. On the Specify the Web Mail Server page, enter the name on the Web site certificate bound to the OWA Web site on the internal network. In this example, the common/subject name on the Web site certificate bound to the OWA Web site is owa.msfirewall.org, so we enter that name in the Web mail server text box. Click Next.
  8. On the Public Name Details page, select the This domain name (type below) option in the Accept requests for drop down list. Enter the name on the Web site certificate that will be bound to the Web listener used for this Web Publishing Rule. Since the common/subject name on the Web site certificate that will be bound to this Web Publishing Rule is owa.msfirewall.org, we will enter that value into the Public name text box and click Next.


Figure 1

  1. On the Select Web Listener page, click New to create the new Web listener.
  2. On the Welcome to the New Web Listener Wizard page, enter OWA SSL in the Web listener name text box and click Next.
  3. On the IP Addresses page, put a checkmark in the External checkbox. If there were more than one IP address bound to the external interface of the ISA firewall, we would select the Address button and configure the listener to use the specific IP address that owa.msfirewall.org resolves to. Click Next.
  4. On the Port Specification page, remove the checkmark from the Port Specification checkbox. Put a checkmark in the Enable SSL checkbox. Click the Select button.
  5. In the Select Certificate dialog box, select the Web site certificate from the Certificates list and click OK.


Figure 2

  1. Click Finish on the Completing the New Web Listener Wizard page.
  2. Click Edit on the Select Web Listener page.
  3. On the OWA SSL Properties dialog box, click the Preferences tab.
  4. On the Preferences tab, click the Authentication button.
  5. Remove the checkmark from the Integrated checkbox. Click OK in the dialog box indicating that no authentication protocol is selected.
  6. Put a checkmark in the OWA Forms-Based checkbox.
  7. Put a checkmark in the Require all users to authenticate checkbox.
  8. Click OK in the Authentication dialog box.
  9. Click OK in the OWA SSL Properties dialog box.
  10. Click Next on the Select Web Listener page.


Figure 3

  1. On the User Sets page, click the All Users entry and click Remove. Click Add.
  2. In the Add Users dialog box, double click the All Authenticated Users entry and click Close.
  3. Click Next on the User Sets page.
  4. Click Finish on the Completing the New Mail Server Publishing Rule Wizard page.

Creating the Redirect Absent Path to Exchange Web Publishing Rule

The next step is to create the Web Publishing Rule to protect us from users who enter the correct protocol, but forget to enter the /exchange path. This rule will use the ISA firewall’s redirect feature so that all connections to https://owa.msfirewall.org for all paths are directed to the /Exchange folder on the OWA site.

Perform the following steps to create the Web Publishing Rule:

  1. In the ISA firewall console, expand the server name and the click the Firewall Policy node. Click the Tasks tab in the Task Pane and click the Publish a Secure Server link.
  2. On the Welcome to the SSL Web Publishing Rule Wizard page, enter the name Redirect Absent Path to Exchange in the SSL Web publishing rule name text box and click Next.
  3. On the Publishing Mode page, select the SSL Bridging option and click Next.
  4. On the Select Rule Action page, select the Allow option and click Next.
  5. On the Bridging Mode page, select the Secure connection to clients and Web server option and click Next.
  6. On the Define Website to Publish page, enter the name that is on the Web site certificate bound to the OWA Web site on the internal network. In this example the common/subject name on the Web site certificate is owa.msfirewall.org, so we enter that value into the Computer name or IP address text box. In the Path text box, enter the path we want to redirect the requests to, which is /Exchange\. Place a checkmark in the Forward the original host header instead of the actual one (specified above) checkbox. Click Next.
  7. On the Public Name Details page, confirm that the This domain name (type below) option is selected in the Accept request for drop down list. Enter the name on the Web site certificate bound to the Web listener that listens for requests for this rule. In this example the Web site certificate bound to the Web listener has the common/subject name owa.msfirewall.org, so we enter that name into the Public name text box. In the Path text box, enter /*. This allows the ISA firewall to redirect requests using any path to the /Exchange folder on the OWA Web site. Click Next.
  8. On the Select Web Listener page, click the down arrow in the Web listener list and click the OWA SSL listener. Click Next.
  9. On the User Sets page, click the All Users entry and click Remove. Click the Add button.
  10. In the Add Users dialog box, double click the All Authenticated Users entry and click Close.
  11. Click Next on the User Sets page.
  12. Click Finish on the Completing the New SSL Web Publishing Rule Wizard page.

Creating the Redirect HTTP to HTTPS Web Publishing Rule

The last rule protects us from users who refuse to use the correct protocol. When users enter http://owa.msfirewall.org (with or without a path), they will be automatically redirected to https://owa.msfirewall.org. This redirect sends them to the Redirect Absent Path to Exchange rule, which enables them access to the /Exchange folder and gets them on their way to success.

Perform the following steps to create the Redirect HTTP to HTTPS rule:

  1. In the ISA firewall console, expand the server name and click the Firewall Policy node. On the Firewall Policy node, click the Tasks tab in the Task Pane and then click the Publish a Web Server link.
  2. On the Welcome to the New Web Publishing Rule Wizard page, enter a name for the rule in the Web Publishing Rule name text box. In this example we will name the rule Redirect HTTP to HTTPS and click Next.
  3. On the Select Rule Action page, select the Allow action and click Next.
  4. On the Define Website to Publish page, enter the FQDN used to access the site in the Computer name or IP address text box. In this example, users access the OWA site using the FQDN owa.msfirewall.org, so we will enter that value into the text box. In the Path text box, we want to allow all paths to be accepted by this rule, so we will enter /* in the text box. Click Next.
  5. On the Public Name Details page, select the This domain name (type below) option in the Accept requests for drop down list. In the Public name text box, enter the FQDN of the OWA site on the internal network. Because we are using a well-designed configuration that includes a split DNS infrastructure, we will use the same FQDN to access the internal site as we use to access the site externally, so we will enter owa.msfirewall.org in the Public name text box. We don’t care about the internal path, since it won’t be preserved in the redirect, so enter /* in the Path text box. Click Next.
  6. On the Select Web Listener page, click the New button. We need to create a new Web listener because we need an HTTP listener, and we only have an SSL listener so far.
  7. On the Welcome to the New Web Listener Wizard page, enter a name for the HTTP listener in the Web listener name text box. In this example, we’ll name the HTTP Web listener HTTP Listener. Click Next.
  8. On the IP Addresses page, put a checkmark in the External checkbox. Since we only have a single IP address bound to the external interface of the ISA firewall, we can just check the checkbox. However, if we had multiple IP addresses bound to the external interface of the ISA firewall, we would have clicked the Address button and selected the specific address that resolves to the FQDN of the OWA site. Click Next.
  9. On the Port Specification page, confirm that the Enable HTTP checkbox is enabled and that the default port is set to 80. Click Next.
  10. Click Finish on the Completing the New Web Listener Wizard page.
  11. Click Next on the Select Web Listener page.
  12. On the Users Sets page, you can accept the All Users entry, since authentication is not required at this point. The users will be immediately redirected to the https:// site, so asking for credentials at this point just increases overhead and may cause other problems. Click Next.
  13. Click Finish on the Completing the New Web Publishing Rule Wizard page.
  14. Right click on the Redirect HTTP to HTTPS rule and click Properties.
  15. In the Redirect HTTP to HTTPS Properties dialog box, click the WebDirect tab.
  16. On the WebDirect tab, put a checkbox in the Send HTTP Redirect checkbox. In the All requests matching this rule will be redirected to this target server text box, enter the FQDN you want to redirect to. In this example we want to redirect to the same FQDN, but to a different protocol. Enter owa.msfirewall.org in the text box, then select the HTTPS option in the Protocol of target server section. Click Apply and then click OK.

The last step is to reorder the rules so that they’re in the following order:

  1. OWA
  2. Redirect Absent Path to Exchange
  3. Redirect HTTP to HTTPS

Then click Apply to save the changes to ISA firewall policy and click OK in the Apply New Configuration dialog box.


Figure 4

Testing and Analyzing the Configuration

Now let’s test the configuration to see if the rules we created actually protect us from fat-fingered or otherwise non-compliant users who don’t use the correct path or protocol. We can test by issuing the following URLs:

  • http://owa.msfirewall.org  This is the nightmare scenario user, who refuses to enter the proper path and uses the incorrect protocol
  • https://owa.msfirewall.org This user makes a big effort to get the protocol right, but URL typing fatigues them and so they leave the path out
  • https://owa.msfirewall.org/exchange This is the responsible user, who enters the correct protocol and path

For the first test, enter the URL http://owa.msfirewall.org in the browser and press ENTER. The OWA forms-based authentication screen appears. Enter valid credentials and click Log On in the OWA FBA screen. The relevant log file entries appear below.

192.168.1.164

127.0.0.0

1

http

Redirect HTTP to HTTPS

http://redirect:https://owa.msfirewall.org/

192.168.1.164

192.168.1.70

443

https

http://owa.msfirewall.org/

192.168.1.164

192.168.1.70

443

https

http://owa.msfirewall.org/CookieAuth.dll?GetLogon?url=%2F&reason=0

192.168.1.164

192.168.1.70

443

https

http://owa.msfirewall.org/CookieAuth.dll?GetPic?image=logon_IE_top.gif

192.168.1.164

192.168.1.70

443

https

http://owa.msfirewall.org/CookieAuth.dll?GetPic?image=spacer.gif

192.168.1.164

192.168.1.70

443

https

http://owa.msfirewall.org/CookieAuth.dll?GetPic?image=logon_Microsoft.gif

192.168.1.164

192.168.1.70

443

https

http://owa.msfirewall.org/CookieAuth.dll?GetPic?image=logon_logo.gif

192.168.1.164

192.168.1.70

443

https

http://owa.msfirewall.org/CookieAuth.dll?GetPic?image=logon_IE_bot.gif

192.168.1.164

192.168.1.70

443

https

http://owa.msfirewall.org/CookieAuth.dll?Logon

192.168.1.164

10.0.0.2

443

https

Redirect Absent Path to Exchange

http://owa.msfirewall.org:443/Exchange%5C

192.168.1.164

10.0.0.2

443

https

OWA

http://owa.msfirewall.org:443/Exchange/

192.168.1.164

10.0.0.2

443

https

OWA

http://owa.msfirewall.org:443/Exchange/Administrator/?Cmd=navbar

192.168.1.164

10.0.0.2

443

https

OWA

http://owa.msfirewall.org:443/Exchange/Administrator/Inbox/?Cmd=contents

192.168.1.164

10.0.0.2

443

https

OWA

http://owa.msfirewall.org:443/exchweb/6.5.7226.0/controls/tf_TwoLine.xsl

192.168.1.164

10.0.0.2

443

https

OWA

http://owa.msfirewall.org:443/Exchange/Administrator/Inbox/

192.168.1.164

10.0.0.2

443

https

OWA

http://owa.msfirewall.org:443/Exchange/Administrator/Calendar

192.168.1.164

10.0.0.2

443

https

OWA

http://owa.msfirewall.org:443/Exchange/Administrator/Tasks

192.168.1.164

10.0.0.2

443

https

OWA

http://owa.msfirewall.org:443/Exchange/Administrator/Tasks

192.168.1.164

10.0.0.2

443

https

OWA

http://owa.msfirewall.org:443/Exchange/Administrator/Calendar

Notice what happens here. The first request triggers the Redirect HTTP to HTTPS rule, which performs the redirect http://redirect:https:/owa.msfirewall.org. This sends the user to the Redirect Absent Path to Exchange rule and generates the FBA log on form. When the user authenticates, he automatically triggers the OWA rule, because its higher in the firewall policy than the other rules and includes the correct path (the path is actually returned to the client from the OWA site, this is why the user doesn’t need to reauthenticate or re-enter URLs.

Now we can test the second rule by entering the correct protocol, but forgetting the path, https://owa.msfirewall.org. Here we can see that the Redirect HTTP to HTTPS rule is not triggered and that the first rule triggered is the Redirect Absent Path to Exchange rule. Then the user triggers the OWA rule and gets access to the site.

192.168.1.164

192.168.1.70

443

https

http://owa.msfirewall.org/

192.168.1.164

192.168.1.70

443

HTTPS

-

192.168.1.164

192.168.1.70

443

https

http://owa.msfirewall.org/CookieAuth.dll?GetLogon?url=%2F&reason=0

192.168.1.164

192.168.1.70

443

https

http://owa.msfirewall.org/CookieAuth.dll?GetPic?image=logon_IE_top.gif

192.168.1.164

192.168.1.70

443

https

http://owa.msfirewall.org/CookieAuth.dll?GetPic?image=spacer.gif

192.168.1.164

192.168.1.70

443

https

http://owa.msfirewall.org/CookieAuth.dll?GetPic?image=logon_logo.gif

192.168.1.164

192.168.1.70

443

https

http://owa.msfirewall.org/CookieAuth.dll?GetPic?image=logon_IE_bot.gif

192.168.1.164

192.168.1.70

443

https

http://owa.msfirewall.org/CookieAuth.dll?GetPic?image=logon_Microsoft.gif

192.168.1.164

192.168.1.70

443

HTTPS

-

192.168.1.164

192.168.1.70

443

https

http://owa.msfirewall.org/CookieAuth.dll?Logon

10.0.0.1

10.0.0.2

443

HTTPS

-

192.168.1.164

10.0.0.2

443

https

Redirect Absent Path to Exchange

http://owa.msfirewall.org:443/Exchange%5C

192.168.1.164

192.168.1.70

443

HTTPS

-

192.168.1.164

192.168.1.70

443

HTTPS

-

192.168.1.164

192.168.1.70

443

HTTPS

-

192.168.1.164

10.0.0.2

443

https

OWA

http://owa.msfirewall.org:443/Exchange/

192.168.1.164

10.0.0.2

443

https

OWA

http://owa.msfirewall.org:443/Exchange/Administrator/?Cmd=navbar

10.0.0.1

10.0.0.2

443

HTTPS

-

192.168.1.164

192.168.1.70

443

HTTPS

-

192.168.1.164

10.0.0.2

443

https

OWA

http://owa.msfirewall.org:443/Exchange/Administrator/Inbox/?Cmd=contents

192.168.1.164

10.0.0.2

443

https

OWA

http://owa.msfirewall.org:443/exchweb/6.5.7226.0/controls/tf_TwoLine.xsl

192.168.1.164

10.0.0.2

443

https

OWA

http://owa.msfirewall.org:443/Exchange/Administrator/Inbox/

192.168.1.164

10.0.0.2

443

https

OWA

http://owa.msfirewall.org:443/Exchange/Administrator/Calendar

192.168.1.164

10.0.0.2

443

https

OWA

http://owa.msfirewall.org:443/Exchange/Administrator/Tasks

192.168.1.164

10.0.0.2

443

https

OWA

http://owa.msfirewall.org:443/Exchange/Administrator/Calendar

192.168.1.164

10.0.0.2

443

https

OWA

http://owa.msfirewall.org:443/Exchange/Administrator/Tasks

We won’t go test the OWA rule separately, since we already know that it works from the previous two examples. When the user enters the correct protocol and path, https://owa.msfirewall.org/exchange they will immediately get the FBA log on page and gain access to the OWA Web site.

Remember to Force Authentication at the ISA Firewall

Its critical that you force authentication on the Redirect Absent Path to Exchange Rule at the ISA firewall. In this example, we forced authentication in two ways: we configured the Web listener to always ask users to authenticate and we configured the rule to apply only to authenticated users. Forcing authentication at the listener and configuring the rule to apply to only authenticated users is a bit redundant, but I do this as a fault tolerant safety measure to make sure that no mistakes are made along the way and that authentication is always forced at the ISA firewall.

If you do not force authentication, and do not use FBA for the Redirect Absent Path to Exchange Rule, some very strange and dysfunctional things will happen. First, you’ll be presented with a authentication dialog box and not the FBA form generated by the ISA firewall. After you authenticate, you’ll find the browser stuck in an apparent endless loop.

However, if you don’t force authentication on the Redirect Absent Path to Exchange Rule, but you do use FBA authentication, then you’ll first see the authentication dialog box and then be presented with the form. After logging in via the form, then you’ll be able to access the site.

Bottom line: When creating the rules, create the Redirect Absent Path to Exchange Rule so that is authenticates the user and uses FBA, as described in this article.

Summary

In this article we went over the procedures required to support users who can’t enter the correct protocol or path when accessing the Exchange Server’s OWA Web site. Three rules are created: one created by the OWA Web Publishing Rule Wizard, one that redirects requests to the correct path when a path isn’t included in the request (or when the wrong path is included), and a rule that redirects the HTTP protocol to the HTTPS protocol. While the path redirection can be accomplished securely using the ISA firewall’s built-in path redirection feature, you need some help to get the complete solution that redirects both path and protocols. WebDirect solves this problem for you and provides critical HTTP functionality which is absent from the out of the box ISA firewall installation.

If you missed the first part of this article please read, Using ISA to Redirect OWA Users to the Correct Directories and Protocols (Part 1).

Featured Links