Publishing Exchange 2003 Outlook Web Access (OWA) with ISA Server 2000 – Part 5: Creating the OWA Web Publishing Rule, Configuring DNS and Installing URLScan 2.5 for ISA Server Firewalls

In the first part of this series on how to publish the Exchange 2003 OWA site using ISA Server 2000, we went over some of the advantages the Exchange 2003 OWA site has over previous versions and a high level overview of the steps required to make the internal Exchange 2003 OWA available to external network users via ISA Server 2000 Web Publishing Rules. If you missed that article, you can check it out here.

In the second part of this series we went over the concept of SSL bridging and how SSL ISA Server 2000 bridging provides unique protection in a way that no other firewall in its class can provide for your OWA 2003 Web site. We then had a short discussion on certificate services and enterprise CAs and ended up with a detailed account of how to install and configure an enterprise CA. If you need a refresher on what we did, check it out here.

In the third part of this series we expanded on the SSL bridging concept. Then we requested a certificate for the OWA Web site and exported that certificate with its private key to a file. Finally, we forced SSL on the OWA directories. Check out this article here.

In the fourth part of this series we imported the OWA Web site certificate into the ISA Server firewall’s machine certificate store. Then we bound the OWA Web site’s certificate to the ISA Server firewall’s Incoming Web Requests listener. We ended up with creating a Destination Set to use in the OWA Web Publishing Rule. You can find part 4 of the article here.

In this, part five and the last article in the series, we’ll cover the following:

Step 11: Creating the OWA Web Publishing Rule

All the elements are in place to create the OWA Web Publishing Rule. Note that while we could have used the ISA Server 2000 Feature Pack 1 Outlook Web Access Web Publishing Rule Wizard, we’ll create the Rule manually so that you have a better understanding of the processes and principles that underlie the rule.

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

1. Open the ISA Management console, expand your server name and expand the Publishing node in the left pane of the console. Click on the Web Publishing Rules node and then right click on it. Point to New and click on Rule.

2. Give the rule a name on the Welcome to the New Web Publishing Rule Wizard page. In this example, we’ll call the rule OWA2003 Web Site. Click Next.
3. On the Destination Sets page, select the Specified destination set option on the Apply this rule to drop down list. Select the OWA Web site destination set from the Name drop down list box. Click Next.

4. On the Client Type page you can control who can use this rule. We’ll take advantage of the ISA Server 2000 Feature Pack 1 option later to allow the ISA Server firewall to pre-authenticate incoming requests by forwarding basic credentials to the OWA Web site. At this point we’ll select the Any request option. Click Next.
    
   
5. On the Rule Action page, select the Redirect the request to this internal Web server (name or IP address) option. In the text box under this option, type in the FQDN of the OWA Web site that is the same as the FQDN listed in the common name of the certificate and the name the external users use to access the site. This prevents you from getting sever error 500 messages and certificate mismatch problems. The key to making this redirect work is a split DNS infrastructure or a HOSTS file entry for the FQDN of the OWA Web site that resolves to the internal address of the OWA site. We’ll cover this issue more in the DNS discussion later in the article.

Put a checkmark in the Send the original host header to the publishing server instead of the actual one (specified above) checkbox. While this option should not be required because of the entry we’ve make in the redirect, we’ll do so anyway to be consistent with the rest of the OWA publishing documentation currently available J.

Do not change any of the entries for HTTP, SSL or FTP bridging. Click Next.

6. Review your settings on the Completing the New Web Publishing Rule Wizard page and click Finish.
7. Double click on the new Web Publishing Rule in the right pane of the console. In the OWA Web Site Properties dialog box, click on the Action tab. On the Action tab, put a checkmark in the Allow delegation of basic authentication credentials checkbox. Click Apply.

8. Click the Bridging tab in the OWA Web Site Properties dialog box. Confirm that in the Redirect SSL requests as option is set to SSL requests (establish a new secure channel to the site). This allows for SSL to SSL bridging.

Place a checkmark in the Require secure channel (SSL) for published site checkbox. This forces the external network client that is trying to connect to the OWA Web site to use SSL in the connection request. If the external OWA client does not make an SSL request, the request will be denied by the Web Publishing Rule.

Place a checkmark in the Require 128-bit encryption checkbox. This forces all OWA Web site clients to use 128-bit encryption. All Microsoft clients support 128-bit encryption, so you should enable this option.

Click Apply, and then click OK.

Note:
Do not enable the Use a certificate to authenticate to the SSL Web server option. This option is used only if you require certificate-based user authentication at the OWA Web site on the internal network. In this example we are allowing basic authentication at the OWA Web site, not certificate-based user authentication. Therefore, we do not need the Web Proxy service to present a user certificate to the OWA Web site on the internal network for authentication purposes. One of the most common errors ISA Server administrators make when configuring OWA Web Publishing Rules is to select the checkbox and wonder why they cannot find a certificate when they click the Select button. The reason why they can’t find a certificate is that the Web Proxy service does not have a user certificate. Please refer to ISA Server and Beyond for details on how to configure certificate-based user authentication on the OWA Web site and how to configure the Web Proxy service to present a user certificate to the OWA Web site.

DNS Issues in OWA Web Publishing and Using a HOSTS File

DNS issues constantly hound the ISA Server 2000 firewall administrator. The single most common cause for ISA Server 2000 questions relates to some kind of DNS issue that hasn’t been completely resolved. DNS is a complex issue with many variables whose values change depending on the environment the ISA Server firewall finds itself in.

In regard to Outlook Web Access site publishing, there are three specific DNS issues you need to address:

Your external network users must be able to access the OWA Web site using the same FQDN listed in the common name field on the Web site certificate, and the FQDN used in the Destination Set included in the OWA Web Publishing Rule. There must be a DNS resource record entry on your publicly available DNS servers that resolve this name to the IP address you used for your Incoming Web Requests listener that you bound the OWA Web site certificate to.

If your ISP hosts your public DNS, then have them configure a Host (A) record for your OWA Web site. In this example, the name on our OWA Web site certificate common name entry is www.internal.net. Therefore, we create a Host (A) resource record on our public DNS for www.internal.net and associate it with the IP address 172.31.0.2 (which is the IP address we selected for the Incoming Web Requests listener that we bound the OWA Web site certificate to). The same procedures would apply if you host your own public DNS servers.

If only external network users access the OWA Web site, then you don’t have to worry about DNS entries to support internal network users. However, if you do have internal network users who need to use the OWA Web site, then you need to create DNS entries to support these users. The DNS entries you created to support the external network users are not appropriate for the internal network users.

You do not want the internal network users to use the external network DNS entries. That would cause internal network users to loop back through the external interface of the ISA Server firewall to access internal network resources. This wastes precious processor and memory resources on the firewall and is not supported for SecureNAT and Firewall clients. Web Proxy clients can loop back through the external interface of the ISA Server firewall to access internal network resources, but this should be considered a worst practice.

You need to create a split DNS infrastructure to support internal network clients. The split DNS infrastructure prevents the internal network clients from looping back through the ISA Server firewall to access internal network resources. Instead, the internal network clients directly access the OWA Web server on the internal network.

There are three things required to make this work for the internal network clients:

The heart or the split DNS is that there are two DNS zones for the same domain name: an external DNS zone with resource records appropriate for external network clients, and an internal DNS zone with resource records appropriate for internal network clients. The external DNS zone record for the OWA Web site has the external IP address on the ISA Server firewall that’s used by the Incoming Web Requests listener to accept requests for the OWA Web site, and the internal DNS zone has resource records with the internal IP address of the OWA server.

The Firewall client uses the Local Domain Table (LDT) to determine which sites should be accessed via the Firewall Service on the ISA Server firewall, and which sites should be access by the internal network client directly. In our current example, the internal network domain is internal.net and the OWA Web site is accessible via www.internal.net. We put the domain name, internal.net, into the LDT. This prevents the Firewall client software from intercepting the request. Since the Firewall client software does not intercept the request, the internal network client is able to connect directly to the OWA Web site on the internal network.

The Web Proxy client can also leverage the LDT. Normally, Web Proxy clients always allow the Web Proxy service on the ISA Server firewall to resolve names on their behalf. When you configure the LDT with the domain name of the OWA Web site, and then configure the Web Proxy client properties on the ISA Server Management console to use the LDT for Direct Access, then the Web Proxy client can use the internal DNS zone to resolve the name of the OWA Web site and directly access the OWA site on the internal network.

Most organizations prefer to use the full Outlook client (Outlook 2000/2002/2003) on the internal network and only use the OWA site when the full Outlook client is not available. In this case, you do not need to split DNS configuration to support the OWA Web Publishing Rule for internal network users.

However, you still need to provide a mechanism for the ISA Server firewall to resolve the FQDN of the OWA Web site to the internal IP address of the OWA Web site on the internal network. You can do this by creating a simple HOSTS file entry. This is what we’ll do in our current example, as we need to provide this information so that the FQDN contained in the redirect in the Web Publishing Rule resolves to the internal address of the OWA Web site.

Perform the following steps to create this HOSTS file entry:

1. Open the Windows Explorer and navigate to <systemroot>\system32\drivers\etc.
2. Double click on the Hosts file in the right pane. In the Open With dialog box, select Notepad from the list of applications and click OK.
3. Add a line after the localhost entry that includes the IP address and FQDN of your OWA Web site. In this example, the OWA Web site’s common name, and the name included in the redirect is www.internal.net, so we add this to the HOSTS file, along with the IP address of the OWA Web site on the internal network. Make sure that you press ENTER after you enter the line so that the insertion point appears under the new entry.

4. Click the File menu and click Save.
5. Close Notepad.

At this point the OWA Web Publishing Rule is fully functional. If you have your public DNS entries in place, you will be able to go to any external network location and access the OWA Web site using Internet Explorer 5.0 and above.

Installing URLScan 2.5 on the ISA Server Firewall

You can increase the level of protection afforded by your OWA Web Publishing Rule by installed URLScan 2.5 on the ISA Server firewall. This version of URLScan was created specifically for ISA Server 2000 and leverages the ISA Server firewall’s unique SSL bridging feature to provide protection for your OWA Web site in a way that no other firewall in its class can provide.

Please review the URLScan documentation in the ISA Server 2000 Feature Pack 1 Help file and online documentation before installing it on the ISA Server 2000 firewall.

Perform the following steps to install URLScan 2.5 on your ISA Server firewall:

1. Download the URLScan 2.5 application from the Microsoft Web site. The specific file is the isafp1ur.exe.
2. Double click on the isafp1.exe file. In the Choose Directory For Extracted Files dialog box, type in a local path for the extracted file in the Choose Directory for Extracted Files dialog box, then click OK.
3. Read the EULA on the URLScan Web Filter for ISA Server Feature Pack 1 dialog box and then click I Agree.
4. A Microsoft ISA Server 2000 Update Setup dialog box appears warning you that URLScan may negatively impact the functionality or accessibility of Web sites you’ve published to external network users. Make sure you have tested the effects of using URLScan in your lab before applying it to the ISA Server 2000 firewall. Click Yes to confirm your understanding of the risk of installing URLScan 2.5.

5. A Microsoft ISA Server 2000 Update Setup dialog box appears asking if you want to use a URLScan.ini file that has been customized to provide secure access to published OWA Web sites. Click Yes to use the OWA specific URLScan.ini file.

6. Click OK in the Microsoft ISA Server 2000 Update dialog box. Leave the checkmark in the Read about the URLScan Web Filter checkbox to get more information about URLScan and ISA Server.
7. Return to the ISA Management console. Expand the server name and then expand the Extensions node. Notice in the right pane of the console a new Web filter, URLScan filter. The filter is enabled by default.

Summary

In this, part 5 or our 5 part series on publishing OWA 2002 Web site, we went over how to create the OWA Web Publishing Rule and then customize the rule to support delegation of basic authentication. Then you learned about how to configure DNS and HOSTS file entries to support the ISA Server firewall, external network hosts and internal network hosts. Finally, we went over how to install URLScan 2.5 on the ISA Server firewall to further enhance security for your OWA Web site.

clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy!