Community Area

by
Thomas Shinder
[Published on 12 July 2005 / Last Updated on 20 May 2013]

A frequent request I see on the ISAServer.org Web boards and mailing lists is for information on how to help hapless uses who can’t remember to enter the correct path or protocol to reach the Exchange Server’s OWA site. While it might seem like a simple issue to enter the path https://owa.domain.com/exchange into the Web browser Address bar and press ENTER, long experience tells us that this isn’t the case.

A frequent request I see on the ISAServer.org Web boards and mailing lists is for information on how to help hapless uses who can’t remember to enter the correct path or protocol to reach the Exchange Server’s OWA site. While it might seem like a simple issue to enter the path https://owa.domain.com/exchange into the Web browser Address bar and press ENTER, long experience tells us that this isn’t the case.

There are three common errors users make when trying to access the OWA site:

Then there are the users who are exceptionally challenged by what life puts in front of them. Instead of entering https://owa.domain.com/exchange, they enter http://owa.domain.com. They enter both an incorrect protocol and path.

In this article we’ll explore how to fix each of these issues and in the process, introduce you to a cool product called WebDirect.

Redirecting Users to /Exchange Folder

A common desire among ISA firewall administrators is to redirect connections to the root of the OWA Web site to the /Exchange folder on the Outlook Web Access (OWA) Web site. You can perform this path redirection easily by using a path redirection on the Path tab in the Web Publishing Rule.

In the case of OWA publishing, the external path is /* (which represents all folders and directories on the site) and the internal path is /Exchange\. Notice that you must use a backslash at the end of the path because the OWA Web Publishing Rule Wizard already entered the /Exchange/ path The paths tab with this type of OWA configuration would look like that seen in figure the figure below.

Figure 1

These path redirections do the following:

When the user enters https://owa.domain.com/exchange in the browser to connect to the OWA site, the connection is directed to the /Exchange folder on the OWA Web site

When the user enters (or clicks a link to) https://owa.domain.com/exchweb, the connection is redirected to the /Exchweb folder on the OWA Web site

When the user enters (or clicks a link to) https://owa.domain.com/public, the connection is redirected to the /Public folder on the OWA Web site.

When the user enters (or clicks a link to) https://owa.domain.com, the connection is redirect to the /Exchange folder on the OWA Web site.

The reason why this works is because the OWA Web site is kind enough to help users who don’t understand the difference between UNC paths and URLs. The OWA Web site will accept the backslash as a valid request and convert it on the fly to a forward slash. This allows you to use the Internal Path statement /Exchange\ and /exchange/* in the Path tab, where it would otherwise not be possible to do this if you had to enter forward slashes for both entries because the ISA firewall will not allow you to enter multiple path mappings that use the same path prefix.

Just to make this clear, the reason why we must enter /Exchange\ in order to get the redirect is that we already have a redirect for /Exchange/*, which is associated with connections users make when they enter https://owa.domain.com/exchange. We can't enter the same path twice, so we need to trick the ISA firewall’s Web Publishing Rule by using /Exchange\ instead, which is associated connections made to https://owa.domain.com/.

OK, this solves the problem of the path challenged users, but what about protocols? We now need a method to redirect the protocol challenged users to the correct protocol.

Redirecting HTTP Users to the SSL Site

Even if you spend months or years trying to teach users how to enter the /exchange path after the FQDN, you’ll end up losing the war because there will always be a large cadre of users who refuse to enter https:// instead of http://. Actually this pack of users can’t be bothered with the protocol prefix, so they’re just enter path, even when they know they need to enter https://.

What we need is a method to redirect users using http:// in the request to the https:// site. There are several ways you can do this:

Create a Web page at that provides a link for users to click, which takes them to the https://owa.domain.com/exchange site. Replace the HTTP 403.4 error page associated with using the incorrect protocol. Replace the ISA firewall’s error page for HTTP 403.4 with this page

Create a Web page that includes a meta redirect that points users to the https://owa.domain.com/exchange site and use the page as a replacement for the HTTP 403.4 error page on the ISA firewall.

The best solution is to use Jim Harrison’s pages. When users connect using the incorrect protocol, they are automatically redirected to the correct protocol and site URL. Jim did a great job here and makes it easy to solve this problem. Download his redirect files contained in ISA_Redirects.zip on the www.isatools.org Web site.

So far, we’ve been able to protect ourselves from users who can’t remember to enter the correct path, and we’ve been able to shore up our defenses against users who can’t get the right protocol, but what do we do with your nightmare scenario where the user refuses to enter the correct path and protocol?

The best solution I’ve seen for this so far is to use WebDirect, which you can get at www.collectivesoftware.com. We’ll go over how WebDirect solves this problem in the next section.

Redirecting Paths and Protocols with the Help of Web Direct

WebDirect is a simple tool that enables the ISA firewall to send HTTP redirects to the user. You can use WebDirect to redirect the user to another site using the same protocol, to another site using a different protocol, or to the same site using a different protocol. WebDirect provides key functionality to the ISA firewall that really should have been included with the product.

We can use WebDirect together with the ISA firewall’s path mapping feature to save us from all the users we’ve being discussing in this article: the path forgetter, the protocol abuser and the hybrid path forgetting protocol abuser.

A rule that redirects users who forgot the path to the /Exchange folder

A rule that redirects the protocol forgetters to the rule that redirects the path forgetters to the /Exchange folder

The rules will end up looking like this in the ISA firewall console:

Figure 2

Starting from the bottom, the rules work like this:

The Redirect HTTP to HTTPS rule accepts incoming connections to http://owa.msfirewall.org and all paths to this host. This rule saves us from the users who forget to enter the correct the protocol and path. For example, if the user enters http://owa.msfirewall.org, he will be redirected to https://owa.msfirewall.org. If another user enters http://owa.msfirewall.org/stuff, he will be redirected to https://owa.msfirewall.org. So this rule always saves us from the protocol abusers and those who make some attempt to get the path right, but never quite seem to hit the mark (although they are still getting the protocol wrong of they hit this rule).

The bottom line is that the Redirect HTTP to HTTPS rule listens for all HTTP requests, regardless of path the user might include, to the owa.msfirewall.org domain.

The Redirect Absent Path to Exchange rule protects us from users who remember to use the right protocol, but forget to use the path and only enter the FQDN for the OWA site. When users enter https://owa.msfirewall.org, the connection is automatically redirected to the /Exchange folder on the OWA Web site.

The OWA rule is the rule created by the ISA firewall’s OWA Web Publishing Rule Wizard. We don’t need to make any changes to this rule. This rule applies to users who pay enough attention to enter the correct protocol and path.

I won’t go into the details of how to create an OWA Web Publishing Rule, since that’s covered in detail in our book, on this site, and in the ISA firewall/Exchange Deployment Kit. What I will go over are the following steps:

Click OK on the dialog box indicating that you should restart the Firewall service to ensure that the WebDirect Web filter installed correctly.

If the ISA firewall console is open, close it and then open it again.

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, so that we get the highest level of security and avoid 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 private key and installed in the ISA firewall’s machine certificate store.

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

In the ISA firewall console, expand the server name and click the Firewall Policy node.

Click the Tasks tab in the Task Pane and click the Publish a Mail Server link.

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.

On the Select Services page, put a checkmark in the Outlook Web Access checkbox and click Next.

On the Bridging Mode page, select the Secure connection to clients and mail server option and click Next.

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.

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.

On the Select Web Listener page, click New to create the new Web listener.

On the Welcome to the New Web Listener Wizard page, enter OWA SSL in the Web listener name text box and click Next.

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.

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.

In the Select Certificate dialog box, select the Web site certificate from the Certificates list and click OK.

Click Finish on the Completing the New Web Listener Wizard page.

Click Edit on the Select Web Listener page.

On the OWA SSL Properties dialog box, click the Preferences tab.

On the Preferences tab, click the Authentication button.

Remove the checkmark from the Integrated checkbox. Click OK in the dialog box indicating that no authentication protocol is selected.

Put a checkmark in the OWA Forms-Based checkbox.

20. Put a checkmark in the Require all users to authenticate checkbox.

Click OK in the Authentication dialog box.

Click OK in the OWA SSL Properties dialog box.

Click Next on the Select Web Listener page.

On the User Sets page, click the All Users entry and click Remove. Click Add.

In the Add Users dialog box, double click the All Authenticated Users entry and click Close.

Click Next on the User Sets page.

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:

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.

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.

On the Publishing Mode page, select the SSL Bridging option and click Next.

On the Select Rule Action page, select the Allow option and click Next.

On the Bridging Mode page, select the Secure connection to clients and Web server option and click Next.

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.

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.

On the Select Web Listener page, click the down arrow in the Web listener list and click the OWA SSL listener. Click Next.

On the User Sets page, click the All Users entry and click Remove. Click the Add button.

In the Add Users dialog box, double click the All Authenticated Users entry and click Close.

Click Next on the User Sets page.

Click Finish on the Completing the New SSL Web Publishing Rule Wizard page.

Summary

In this article we went into the issues involved with redirecting users that enter the incorrect protocols and paths into the Web browser when accessing the OWA Web site. We went into the details of the problems related to entering the incorrect protocols, and the challenges presented by users who enter the incorrect paths. We introduced two powerful solutions to the problems presented by these users: one using the built-in path mapping capabilities included with the ISA firewall, and a second using a tool name WebDirect, that gives the ISA firewall the ability to generate an HTTP redirect. In part 2 of this article we’ll finish up the configuration and test it.

Featured Links

Office 365 CON 2015

Registration is now open for Office 365 CON 2015, an annual gathering of IT Strategists, Domain Experts and Microsoft MVPs, presenting the latest technologies, challenges and solutions facing the Exchange and Office 365 community of professionals.

Join Michael Osterman from Osterman Research as he kicks-off the conference by sharing his insights into recent trends and challenges obtained through survey research within the Office 365 and Exchange user communities.

Following the kick-off presentation, you can choose from multiple breakout focus sessions, including: