The Unihomed Web Cache Mode ISA Server, Part 2: Web Publishing Outlook Web Access
The Unihomed Web Cache Mode ISA Server, Part 2: Web Publishing Outlook Web Access
By Thomas W Shinder M.D.
In the first part of this article on the unihomed caching-only ISA Server, I told you about how you can use this configuration to allow outbound access for Web Proxy clients on the internal network. While outbound access control is very nice, it pales in comparison to the ability to use the unihomed caching-only ISA Server to publish Web sites, such as the ever popular Outlook Web Access.
Publishing Outlook Web Access is the most popular, and yet one of the most complex, types of Web Publishing you can perform. This are a myriad of steps and failure to perform a single step correctly will cause the entire house of cards to fail or perform very poorly. You also configure OWA and Exchange Publishing very differently depending on your own environment. I highly recommend that you read over the OWA Publishing material in ISA Server and Beyond before carrying out this procedure, as it includes the steps by steps and explanations of those steps for a variety of OWA publishing scenarios.
One thing that can help make OWA publishing a bit easier is the new OWA Web Publishing Wizard included with ISA Server Feature Pack 1. A second very useful feature included in our OWA Web Publishing Scenario is the Basic authentication forwarding feature included with Feature Pack 1.
Let’s look at the path for inbound connections to our unihomed caching-only ISA Server used for OWA publishing.
- The external client running Internet Explorer sends its request to the Internet connection device. This can be a packet filtering device such as PIX or Checkpoint, or a simple NAT server, such as the Windows 2000 RRAS NAT service. The external client sends the request to the FQDN that resolves to an IP address that you’re using on the external interface of your Internet connection device.
- The packet filtering device is configured to forward requests to TCP 80 and TCP 443 to the unihomed caching-only ISA Server. Its critical that your public DNS is configured correctly and that the FQDN resolves to the correct IP address that you use to forward the packets to ISA Server.
- The unihomed caching-only ISA Server receives the request and forwards it to the OWA Server on the internal network.
- The OWA site answers the request and forwards the answer to the unihomed caching-only ISA Server.
- The unihomed ISA caching-only ISA Server forwards the answer to the client through the packet filtering Internet connection device.
- The Internet connection device forwards the answer from the unihomed caching-only ISA Server to the client on the Internet.
Note that you should be passing these packets through your Internet connection device unmolested. The black box should not attempt to examine or otherwise deconstruct the SSL communication. The ISA Server is the endpoint for all SSL communications with the OWA site.
Publishing OWA on the unihomed caching-only ISA Server is very similar to the other OWA publishing scenarios that I went over in great detail in ISA Server and Beyond. However, I didn’t go over the unihomed configuration in the book and Feature Pack 1 wasn’t available at the time, so consider this article an update to the OWA material in the book.
The basic steps to publishing OWA on the unihomed caching-only ISA Server include:
Let’s look at each of these steps in a bit more detail.
Configuring the Internet Access Device
You need to configure the Internet access device to forward the packets it receives for the OWA site to the internal network unihomed caching-only ISA Server. This port forwarding can be done on virtually any Internet access device. The trick is that you must make sure that the requests arrive on the correct IP address.
For example, if the external user accesses the OWA site via http://owa.domain.com/exchange, then you must have a public DNS entry for owa.domain.com and that DNS Host (A) record must point to the IP address on the external interface of your Internet connection device that is configured to forward packets to the unihomed ISA Server on the internal network.
The specifics of the configuration depend on the Internet connection device you’re using. If you’re using the Windows 2000 RRAS NAT, you would configure the external interface with Special Ports that perform reverse NAT for TCP 80 and TCP 443, as seen in the figure below. Note that this server has a single IP address bound to the external interface. This will limit port forwarding for TCP 80 and TCP 443 to the ISA Server only.
Binding a Certificate to the OWA Site
You always want to use SSL to connect to the ISA Server from the external network client. You don’t want data between the unihomed caching-only ISA Server and the external network client to move in the clear. You should also secure the data moving between the unihomed caching-only ISA Server and the OWA site on the internal network. Why? Because the external network client assumes that you have a secure path from source to destination, and you "break" that trust when you bridge SSL as HTTP. While you certainly can perform SSL to HTTP bridging, I highly recommend that you bridge SSL as SSL. I will cover only the SSL to SSL bridging scenario in this article.
You’ll need to open the Internet Information Services console on the OWA server and get to the Properties page of the Default Web Site. On the Directory Security tab you’ll see the Secure Communications frame. Click on the Server Certificate button and you’ll see the Welcome to the Web Server Certificate Wizard page. Go through the Wizard to obtain a certificate from an online certificate server or to create a certificate request file.
You can use the Microsoft Certificate Server to request a certificate from an Enterprise or a standalone certificate server. You can also make an offline request and email your certificate request to a 3rd party certificate provider. Check your ISA Server and Beyond book for the details of each scenario.
You’ll see the certificate in the OWA server’s certificate store once you successfully obtain the Web site certificate. The figure below shows the Certificates MMC snap-in with the focus on the machine’s account. Pay very close attention to the subject name on the certificate. The users must use the exact name as that used in the subject or common name field of the certificate.
Once you get the certificate bound to the Web site, the next step is to configure the OWA folders to require SSL and to use Basic authentication ONLY. You can play with integrated authentication, digest authentication, etc. all you want, but if you want good performance and a minimum of hassles, use Basic authentication only. SSL protects your credentials, so you don’t have to worry about them being passed in the clear.
You need to configure the following folders:
to force SSL and to use basic authentication. Open the Internet Information Services console on the OWA site and then open the Properties dialog box on one of these folders. Click on the Edit button in the Secure Communications frame. You’ll see what appears in the figure below. Put a checkmark in the Require secure channel (SSL) checkbox to force SSL when connecting to this folder. You should also select the Require 128-bit encryption option if all your internal network clients support this. This ISA Server supports this, so if the ISA Server is the only one accessing the site, go ahead and select this option.
Go back to the Directory Security tab and click on the Edit button in the Anonymous access and authentication control frame. You’ll see what appears in the figure below. You want to remove checkmarks from all of the options except for Basic authentication. If you leave multiple authentication options selected, you will likely have problems with slow authentication or multiple authentication dialog boxes, and when you ask me how to fix it, I’ll tell you to set the folder to use Basic authentication only .
Make sure you enter a default domain to support the Basic authentication. This will allow your users to use just their username and password to access the site. However, users that do not belong to the default domain will still need to enter their domain and username, using the DOMAIN\username format.
Export and Import the Web Site Certificate
After obtaining the Web site certificate and configuring the Web site, the next step is to export the Web site certificate. You want to export the Web site certificate so that you can bind the Web site certificate to the ISA Server’s Incoming Web Requests listener. This allows the ISA Server to impersonate the Web site.
You can export the Web site certificate from the Internet Information Services console. Open the Web site’s Properties dialog box and click on the Directory Security tab. Click on the View Certificate button in the Secure Communications frame. In the Certificate dialog box, click on the Details tab. Click the Copy to File button and use the Wizard to export the certificate.
Once the certificate is exported, copy it to the unihomed caching-only ISA Server. You need to import the certificate into the ISA Server’s machine store. Use the Certificates MMC to import the certificate into the machine’s Personal certificate store. Make sure that the private key is included! It’s hard to encrypt data without the private key. Once the certificate is installed on the ISA Server, you’ll be able to bind it to the Incoming Web Requests listener. Note that if you’ve done everything correctly, you will not need to restart the ISA Server. You will need to close and reopen the ISA Management console.
Creating the Web Publishing Rule using the FP1 OWA Publishing Wizard
Feature Pack 1 includes a new Wizard that you can use to publish OWA sites. The Wizard configures the Incoming Web Requests listener, the Destination Sets, and the Publishing Rule. While the Wizard is far from a "one stop shop" for publishing OWA sites, it does simplify OWA publishing somewhat and I recommend that you give it a try.
- In the ISA Management console, expand your server name and then expand the Publishing node. Right click on Web Publishing Rules, point to New and click Publishing Outlook Web Access Server.
- On the Welcome to the Outlook Web Access Publishing Wizard page type in the name for your rule and click Next.
- On the Name of Published Server page, type in the name of the server in the Internal name or IP address of Outlook Web Access Server text box. Note that I am using the same name that is used by the external client to access the site. Make sure you are using a split DNS, or have a HOSTS file entry on the ISA Server that resolves the name you put here to the internal IP address of the OWA server. We also want to make sure that the connection from the ISA Server to the OWA Web sites is secured with SSL, so put a checkmark in the Use an SSL connection from the ISA Server to the Outlook Web Access Server checkbox. Click Next.
- On the Listeners page, type in the FQDN that the external users use to access the OWA site. Make sure this is the same as the common name you assigned to the Web site certificate. Click Next.
- The Secure Connection from Client page allows you to force an SSL connection between the external client and the Incoming Web Requests listener. Put a checkmark in the Enable SSL. Client must use SSL to connect to the ISA Server checkbox, then click on the Select button. In the Select Certificate dialog box, select the Web site certificate that you imported and click OK. Click Next.
- On the Completing the Outlook Web page, click Finish. An ISA Server Warning dialog box tells you that the Web Proxy service must be restarted. Allow the Wizard to restart the server and click OK.
The Wizard performed the following actions:
The Wizard has done the heavy lifting, but you need to tweak things a bit. I recommend you always use Basic authentication when using SSL to SSL bridging. This will reduce the number of compatibility problems you’ll see and performance will be improved as well. Perform the following steps to support your Basic authentication scheme for OWA access:
- In the ISA Management console, expand your server name and then expand the Publishing node. Click on the Web Publishing Rules node in the left pane of the console and double click on your new OWA Web Publishing Rule.
- In the Web Publishing Rule’s Properties dialog box, put a checkmark in the Allow delegation of basic authentication credentials checkbox.
- Click Apply and then click OK.
- Right click on your server name and click Properties. Click on the Incoming Web Requests tab. Click on the listener created by the Wizard and click Edit.
- Remove the checkmark from the Integrated option and put a checkmark in the Basic with this domain option. Click Yes in the dialog box warning your about data passing in the clear. Click the Select domain option and select the default domain. Click OK.
- Click Apply. Allow the server to restart the Web Proxy service and click OK. Click OK to close the Properties dialog box.
Congratulations! You are done with the OWA site and ISA Server configuration. Your unihomed caching-only ISA Server is now ready to accept requests for your OWA site.
Configuring the External Client
There isn’t too much configuration required on the external network client. All just about any version of Internet Explorer, from 5.0 onward, will work with your Basic authentication setup. Life would not be so simple if you didn’t use Basic authentication and SSL. But since you followed my advice, your external clients can log onto the site with no problems.
One thing you can do to speed things up is to assign the calling machine a machine certificate. While you can’t always do this (because users are using public machines to access the site), it does speed things up to have your certificate server in the list of Trusted Root Certification Authorities. Of course, if you’re using a 3rd party certificate from a public service such as Thawte or Verisign, you won’t have to worry about this problem.
Connect to the Web site using HTTPS and the URL. If users don’t like typing in HTTPS, you can create a Web page that automatically redirects them using the meta tag or use your favorite method of redirection. You might want to create your own log on page that contains a link to the directed site. When the user connects to the site, they’ll see a dialog box like that seen below. You can enter the username and password and click OK. Note that you do not need to enter DOMAIN\username if the user’s account belongs to the default domain.
Once you log on the page should come up very quickly (dependent on the speed of your connection). If the page doesn’t load or loads very slowly, then you forgot to take my advice regarding allowing only basic authentication.
In this article I went over some of the basic procedures required to publish an OWA site with a unihomed caching-only ISA Server. The unihomed caching-only ISA Server can be used to control not only outbound access to Web sites, but can also be used to control inbound access using Web Publishing Rules. You saw how you can protect the contents of the communications using SSL and provide a high level of security by bridging SSL to SSL. We also went over some of the cool features of ISA Server Feature Pack 1, and how these features make publishing OWA easier.
If you are having problems with your OWA publishing, or need a more detailed discussion and step by step examples, then I strongly encourage you to pick up a copy of ISA Server and Beyond. I go into great detail regarding a number of OWA publishing scenarios and I’m sure you’ll find something in there that will help you out.
I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=4;t=000525 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom