Using the ISA 2006 Firewall (RC) to Publish OWA Sites – Single Exchange Server Scenario, Part 2

Using the 2006 ISA Firewall (RC) to Publish OWA Sites – Single Exchange Server Scenario, Part 2
By Thomas W Shinder MD, MVP


Have Questions about the article? 
Ask on the Web boards at http://tinyurl.com/rhkab  

If you missed the previous article in this series please read Using the ISA 2006 Firewall (RC) to Publish OWA Sites – Single Exchange Server Scenario, Part 1.

In part 1 of this two part series on publishing a single Exchange Server’s OWA site, we went over the background principles required for the solution to work and then created the Web Publishing Rule that publishes the OWA site. If you missed that article, check it out at:

http://www.isaserver.org/tutorials/Using-2006-ISA-Firewall-RC-Publish-OWA-Sites-Part1.html

In this, part 2 of the two part series, we’ll finish up by investigating things we can do to customize the Web Publishing Rule to increase security for the published OWA site. We’ll then finish up by reviewing the end-user experience for viewing the OWA site using the full and watered-down versions of OWA and how the user changes his password using the OWA interface.

Customizing the OWA Web Publishing Rule

At this point the OWA Web Publishing Rule will work and users will be able to connect to the OWA Web site using this rule. However, there are some things you can do to tweak the rule. Double click on the OWA rule.

In the OWA Properties dialog box, click the To tab. Here you have the option to specify how the ISA firewall proxies the connections to the published OWA Web site. The default setting is Request appear to come from the ISA Server computer. However, if you want to record the original client IP addresses in your Web server log files, you can select the Requests appear to come from the original client. Note that if you choose for the ISA firewall to preserve the original client IP address, then the published Web server must be configured as a SecureNET client.


Figure 1

Click on the Traffic tab. Here you have two options:

  • Require 128-bit encryption for HTTPS traffic This option allows you to force the clients to use 128bit encryption when connecting to the ISA firewall. Almost all modern browsers are capable of this, but if you want to make sure that no one is able to use an older browser that isn’t capable of 128bit encryption, then you can force that setting here.
  • Require SSL Client Certificate This option allows you to require that the user provide a valid User Certificate before being able to log into the OWA site. The User Certificate must be for the same user who plans on logging into the site via the form.


Figure 2

Click on the Application Settings tab.

Here you can change the Logon type provided to the Exchange Server, where the choices are:

  • As selected by user (public or private)
  • Always public

The option you select here is important in the context of the options you select in the Exchange Publishing Attachment Blocking frame. Here you have the option to block e-mail attachments for clients connecting from Public and/or Private computers.

While it’s nice to have the option to block attachments from public computers but allow them for private computers, the problem is that the ISA firewall doesn’t have a mechanism to determine what machines are public or private. The decision is up to the user. So, you could select the option to block attachments from public computers but allow them for private computers only to have users connecting from public kiosks select the private computer option.

I suppose you could set the option to Always public in the Logon type provided to the Exchange Server drop down box and it would prevent all users from accessing attachments. Only the other hand, you would just select the two checkboxes. So, it’s not really clear why you would care what log on type the user uses if you’re concerned about users violating your trust that they will select the correct logon type.


Figure 3

Click on the Listener tab and the click the Properties button. In the Listener’s Properties dialog box, click on the Forms tab. In the Password Management frame, you have the option to provide your users the ability to change their passwords and to be reminded to change their passwords “X” number of days in advance by using the Allow users to change their passwords and Remind users that their password will expire in this number of days options.

Click on the Advanced button on the Listener’s Properties dialog box and you’ll see some options regarding the use of persistent cookies, private cookies and session timeouts.

Persistent cookies allow the client to use the same cookie across applications and provides a better end user experience, but is less secure because the cookie can potentially be stolen. The default setting is to allow persistent cookies only on private machines. This answers the question I had above regarding what the point was regarding whether you should give users the option to select the type of client they have. The Public versus Private computer setting not only controls attachment behavior, but also controls cookie persistence. Your other two options for Persistent Cookies are Never use persistent cookies and On all computers.

The Ignore browser’s IP address for cookie validation option allows clients to use the same cookie from different IP addresses, such as when the client is located behind a load balancer that reports different source IP addresses for the connections to the ISA firewall’s external  interface.


Figure 4

The Client Security Settings frame in the above graphic allow you to configure the session timeout. The default is set as the maximum idle time that is configured on the Web listener. You can customize this setting by selecting the Treat as maximum session duration and then setting customer time limits for public computers and private computers. You also have the option to Apply session timeout to non-browser based clients such as Outlook RPC/HTTP clients and ActiveSync clients. If you do not enable this option, I assume the session timeout will be the same as the maximum idle time and that no session timeout is set that would force a disconnect.

Have Questions about the article? 
Ask on the Web boards at http://tinyurl.com/rhkab 

HTTP Security Filter Settings

While pre-authentication and authorization are important security functions the ISA firewall provides for protecting your OWA site, the ISA firewall can do much more. Specifically, the ISA firewall can make sure that potentially dangerous HTTP communications are not passed through the ISA firewall to the published Exchange Server’s OWA site. The ISA firewall is able to do this using to key technologies:

  • SSL to SSL bridging (SSL termination and initiation)
  • The HTTP Security Filter

SSL bridging enables the ISA firewall to inspect the contents of an otherwise encrypted tunnel. Unlike hardware firewalls that are unable to view the contents of an SSL tunnel and pass exploits contained in that tunnel to the Web server behind the “hardware” firewall, the ISA firewall is able to crack open the SSL tunnel, perform application layer inspection on the contents, and then re-encrypt the communication so that its forwarded over a secure SSL tunnel to the published Web server.

The HTTP Security Filter does the ISA firewall’s HTTP inspection for potentially dangerous communications that might move over the SSL connection. Because we know what “known good” communications are when connecting to the OWA site, we can configure the HTTP Security Filter to confirm that the connection meets those parameters and if the connection does not meet those parameters, then the connection is dropped.

To configure the HTTP Security Filter, right click the OWA rule and click the Configure HTTP command. This will bring up the Configure HTTP policy for rule dialog box as appears in the figure below.


Figure 5

The table below provides the information you need to complete the configuration of the HTTP Security Filter for a OWA Web Publishing Rule. This information was obtained from the Microsoft article Application Layer Firewall protection for Exchange Server 2003 with ISA Server 2004 found at http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/firewall-exchange2003.mspx

Setting and rule

Outlook Web Access

General tab

 

Maximum headers length

32768

Maximum payload length

10485760

Maximum URL length

16384

Maximum query length

4096

Verify normalization

Yes

Block high bit characters

No

Block responses containing Windows executable content

Yes (Note 1)

Methods tab

 

Allow only specified methods

BCOPY
BDELETE
BMOVE
BPROPPATCH
DELETE
GET
MKCOL
MOVE
POLL
POST
PROPFIND
PROPPATCH
SEARCH
SUBSCRIBE












Extensions tab

 

Action taken for file extensions

Block specified extensions (allow all others)

Extension list

.asax
.ascs
.bat
.cmd
.com
.config
.cs
.csproj
.dat
.dll (Note 2)
.exe (Note 1)
.htr
.htw
.ida
.idc
.idq
.ini
.licx
.log
.pdb
.pol
.printer
.resources
.resx
.shtm
.shtml
.stm
.vb
.vbproj
.vsdisco
.webinfo
.xsd
.xsx































Block requests containing ambiguous extensions

No

Headers Tab

 

Blocked headers

None

Signatures Tab

 

Blocked signatures:
Request URL

./
\
.. (Note 3)
% (Note 3)
& (Note 3)



TABLE 1: HTTP Security Filter Settings for an OWA Web Publishing Rule

Note 1:
Blocking .exe file extensions and enabling Block responses containing Windows executable content for Outlook Web Access will block access to the S/MIME control. If the S/MIME control is required for Outlook Web Access on Exchange Server 2003, do not include .exe in the blocked extensions list or enable Block responses containing Windows executable content.

Note 2:
Blocking .dll file extensions for Outlook Web Access will block access to the online spelling checker that is built into Outlook Web Access.

Note 3:
Including the strings “..”, “%”, and “&” can prevent certain types of potential attacks but it will also reduce access to certain e-mail messages. An e-mail message subject line forms part of the URL to access the message and thus any e-mail message containing one of these characters will be blocked. A balance must be found between extra security and functionality. Do not include the “:” character in this list because this will block access to the majority of e-mail messages. Many message subject lines contains RE: and FW: if they are replies or forwards

Testing the Web Publishing Rule

The proof the pudding is in the eating, so let’s see if what we did actually worked. Start up your Web browser and enter https://owa.msfirewall.org/exchange in the address bar and press ENTER. You’ll see the OWA log on page as it appears in the figure below.


Figure 6

Notice that you have the following options:

  • This is a public or shared computer The user should use this option when connecting from a computer that isn’t a corporate managed machine.
  • This is a private computer The user should use this option when connecting from a corporate managed machine
  • Use Outlook Web Access Light The use should select this option when connecting from a Web browser that isn’t Internet Explorer 6.0 or above, or if the user is on a very slow connection. We’ll look at the user experience with the option later
  • I want to change my password after logging on This option enables the user to change his password from within the OWA interface
  • Domain\user name The user must use the Domain\user name or the [email protected] format to connect to the Exchange Server. If you use RADIUS authentication, they must always use Domain\user name. If you use Basic authentication, the user can enter just his user name (and password, or course).
  • Password The users password is entered here

When you log on you’ll see the OWA site appear, as seen in the figure below.


Figure 7

When you click the Log Off button in the OWA interface, you’ll see the log off page as seen in the figure below.


Figure 8

Let’s take a look at the Outlook Web Access Light user experience. The user selects the Use Outlook Web Access Light option in the OWA log on page and enters his credentials.


Figure 9

The OWA mailbox appears in the browser with a less functional user interface.


Figure 10

Now let’s look at what happens when the user chooses to change his password. On the OWA log on page, the user selects the I want to change my password after logging on option and enters his credentials.


Figure 11

A change password page appears where the user enters his old password, and then types his new password twice. Then he clicks the Change Password button.


Figure 12

After clicking the Change Password button, a page appears that informs the user that the password was changed and that the user will be automatically redirected to his mailbox. If the user is not automatically redirected, he can click the Continue button.


Figure 13

Have Questions about the article? 
Ask on the Web boards at http://tinyurl.com/rhkab 

Summary

In this two part series on publishing an OWA site we focused on the procedures used to publish a single OWA site using the new ISA firewall’s forms-based authentication method. We went over the details of the configuration options and how they can be used to enhance the security the ISA firewall can provide for remote access connections to your OWA site. We finished up by looking at the end-user experience for logging on to OWA, the reduced functionality version of OWA, and how the user changes his password via the OWA interface.

If you missed the previous article in this series please read Using the ISA 2006 Firewall (RC) to Publish OWA Sites – Single Exchange Server Scenario, Part 1.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top