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

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


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

If you would like to be notified of when Tom Shinder releases the next part in this series please sign up to our ISAserver.org Real-Time Article Update newsletter.

The new ISA firewall includes a number of new features that represent improvements over the ISA 2004 firewall Web Publishing feature set. While on the surface some of these improvements lack what I would call the “wow” factor, these features in the end make it easier than ever to create the most secure remote access solution to Exchange Web services on the market today.

To demonstrate some of the changes included with the new ISA firewall, we’ll go over how to publish a single back-end Exchange Server where there are no front-end devices. This provides a simple environment that you can use to test the new ISA firewall and get a taste for the new features it provides to enhance the security of remote access connections to Exchange Server Web services.

The figure below provides a high level view of the example network.


Figure A

Key facts about the network setup include:

  • All machines are part of the same domain. This is an ISA firewall best practice and we keep with best practices around here. I know there might be some moaning from the low brows that maintain the routers on the network, but router people are not security experts. However, we are. If you run into one of these luddites, send them over to this link and if they can’t accept it, send them in for a mental status check
  • On the DC computer are installed Active Directory, DHCP, DNS, Certificate Services and WINS. Not all of these services are required in this scenario, but they all can be leveraged by the ISA firewall in a number of different scenarios. In the current scenario, only the DHCP, DNS, Active Directory and enterprise CA services will be used. WINS is primarily used to support VPN client connections where the VPN client machines are not domain members and thus cannot fully qualify unqualified names correctly
  • A Web site certificate was generated for the back-end Exchange Server’s OWA Web site using the Web Site Certificate Wizard included with IIS to request the certificate from an online enterprise CA. I won’t go over the procedures here, as I’ve documented them many times in the past. If you want to see how to request a certificate from an enterprise CA, check out the ISA 2000 Exchange Deployment Kits docs over at http://www.isaserver.org/img/upl/exchangekit/
  • The name of the Web site certificate bound to the OWA site is owa.msfirewall.org. This certificate was exported, along with its private key, to a file and then imported into the ISA firewall’s machine certificate store. This certificate will be bound to the Web listener that we’ll create later in this article.
  • The CA certificate of the CA issuing the Web site certificate is installed on the ISA firewall. This will happen automatically if the ISA firewall was made a domain member before installing the ISA firewall software. If the ISA firewall was made a domain member after the ISA firewall software was installed, then you will have to go through a somewhat tedious procedure to benefit from certificate autoenrollment. The easiest was to do this is to import the CA certificate into the ISA firewall’s Trusted Root Certificate Authorities machine certificate store manually
  • A split DNS is deployed to support users’ wishes to use the same name to connect to the OWA site regardless of location. This means that users will be able to use the same name to connect to the ISA firewall when they’re on the corporate network or when they’re located somewhere outside the office. For comprehensive details on how to create a well-designed split DNS infrastructure to support this configuration, check out this article.

Once the DNS is configured and certificates are deployed, you’re ready to publish your OWA Server.

To create the Web Publishing Rule, open the ISA firewall console, expand the array name and click the Firewall Policy node. Click the Tasks tab in the Task Pane and click the Publish Exchange Web Client Access link.

On the Welcome to the New Exchange Publishing Rule Wizard page, enter a name for the rule in the Exchange Publishing rule name text box. In this example we’ll use the name OWA. Click Next.


Figure 1

On the Select Services page, select the Exchange Server 2003 option from the Exchange version drop down list. Here you have the following options:

  • Outlook Web Access
  • Outlook RPC/HTTP(s)
  • Outlook Mobile Access
  • Exchange ActiveSync

In this scenario we’re only publishing the OWA site, but there’s no reason why you can’t select the other options. In a future article I’ll focus on configuring the ISA firewall to support Windows Mobile clients. Select the Outlook Web Access option and click Next.


Figure 2

On the Publishing Type page, you have two options:

  • Publish a single Web site or load balancer This option allows you to publish a single server that isn’t part of a Web farm, or if you have a third party load balancer behind the ISA firewall, then you publish that load balancer’s address. If you have a farm of front-end Exchange Servers, I highly recommend that you try to get a refund on your third party load balancer and use the integrated Web Farm support that comes with the new ISA firewall, as you’ll see better performance and reliability, as well as removing a single point of failure, which is what the third party load balancer represents.
  • Publish a server farm of load balanced Web servers This option allows you to publish a Web farm of front-end Exchange Servers using the ISA firewall’s built-in Web Farm publishing capabilities. The built-in Web farm publishing feature provides excellent load balancing, failover and failback, and health monitoring.

In this example we’re publishing a single Exchange Server, so we’ll select the Publish a single Web site or load balancer option and click Next.


Figure 3

On the Server Connection Security page you have two options:

  • Use SSL to connect to the published Web server or server farm This option tells the ISA firewall to use a secure SSL connection between itself and the published Web server. I highly recommend that you always use this option because no network can be trusted. Since no network can be trusted, you want to make sure that even communications moving over the corporate network are encrypted, and this is what this option provides you.
  • Use non-secured connections to connect the published Web server or server farm This option tells the ISA firewall to use an unsecured link between itself and the published Web server. I strongly recommend that you do not use this option because the information between the ISA firewall and the published Web site will not be encrypted and can be easily accessed by anyone with a network sniffer on any interposed network between the ISA firewall’s internal interface and the published Web server.

In this example we’ll use ISA firewall best practices and force a secure SSL link between the ISA firewall and the published Web server. Select the Use SSL to connect to the published Web server or server farm option and click Next.


Figure 4

On the Internal Publishing Details page you enter information about the Web server that you’re publishing. In the Internal site name text box, you enter the common/subject name on the Web site certificate that is bound to the OWA Web site. You must do this because it’s required for the CONNECT process between the ISA firewall’s internal interface and the published Web server. Failure to follow these instructions will lead to the dreaded 500 Server Error.

One major improvement included with the new ISA firewall is the ability to specify a name or IP address of the published Web server. In ISA 2004, the name on the To tab was used both to resolve the name of the published server on the internal network and also provide the name used in the CONNECT.

This was problematic because the name on the Web site certificate bound to the OWA site is almost never the actual name of the server (nor should it be). Because of this, you had to either deploy a split DNS (which you should do anyhow) or enter a HOSTS file entry on the ISA firewall that resolved the common/subject name on the OWA Web site’s certificate to the IP address of the published Web server.

With the new ISA Server 2006 firewall, you don’t have to go through these hoops. The name used for the CONNECT is the one entered in the Internal site name text box and the connection request is sent to the IP address or name you enter in the Computer name or IP address text box after putting a checkmark in the Use a computer name or IP address to connect to the published server. This does simplify things a bit, but I still highly recommend a split DNS infrastructure to support your users who move between the internal and external networks with their laptops.

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 Internal site name text box. The IP address of the machine is 10.0.0.3, so I enter that into the Computer name or IP address text box. Note that if we were using User Certificate authentication in this scenario and Kerberos Constrained Delegation, we would need to enter the actual FQDN of the internal Exchange Server.

Click Next.


Figure 5

On the Public Name Details page, select the This domain name (type below) option from the Accept request for drop down list. You always want to select this option when publishing Web sites. If you select the Any domain name option, you can potentially increase your attack surface, which is something we really don’t want to do.

In the Public name text box, enter the common/subject name of the Web site certificate that will be bound to the Web listener used in this Web Publishing Rule. In this example, we are going to bind the Web site certificate that we bound to the OWA Web site itself, so it will use the same common/subject name as the internal Web site, which in this case is owa.msfirewall.org.

Click Next.


Figure 6

On the Select Web Listener page you can select a Web Listener that you’ve already created or create a new one. Since we haven’t created a Web Listener yet, we’ll click the New button to create the new Web listener.


Figure 7

On the Welcome to the New Web Listener Wizard page, enter a name for the Web Listener. In this example, we’ll name the Web Listener OWA SSL Listener and then click Next.


Figure 8

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

On the Client Connection Security page, you have two options:

  • Require SSL secured connections with clients This option tells the ISA firewall that you want to require the external clients to use a secure SSL connection to connect to the external interface of the ISA firewall. This is the option you should select in almost all cases except for the scenario where you are publishing a central OWA server from branch office locations. Failure to enforce SSL connections from external clients to the external interface of the ISA firewall
  • Do not require SSL secured connections with clients This option enables the use of an unsecure connection between the client and the external interface of the ISA firewall. Never use this option unless you’re using the methodology discussed in my branch office article.

In this example we’re using ISA firewall best practices, so we’ll select the Require SSL secured connections with clients and click Next.


Figure 9

On the Web Listener IP Address page you select what ISA firewall Networks and IP addresses on which you want the ISA firewall to accept incoming connections. In our example, we want both external users and internal users to be able to access the OWA site. To do this, we put checkmarks in the External and Internal checkboxes. Note that we have a split DNS infrastructure already configured that will support using the same name regardless of the users location.

If you have multiple IP addresses bound to any interface on the ISA firewall, you should click the Select IP Addresses button and select the specific IP address on which you want the listener to accept the incoming connections. This increases your options, because if you configure the Web Listener to listen on all IP addresses, you can’t create any other listeners because the SSL socket will already be bound to all the addresses.

In this example we only have one IP address bound to each interface, so we’ll select the External and Internal Networks and click Next.


Figure 10

On the Listener SSL Certificates page, you select the certificates that you want bound to the Web listener. In our current example we only have a single certificate. However, we could use this listener to publish multiple Web sites using different common names and bind all of those certificates to this listener. This is useful for a single sign-on environment where you want the OWA users to have access to a published SharePoint Portal Server site without having the users log in again.

Note that in the scenario where you want to bind multiple certificates to the Web listener, the Web Listener must be listening on more than one IP address, as you can only bind a certificate to a single IP address.

In this example, click the Select Certificate button. In the Select Certificate dialog box, you’ll see a list of certificates that can be used in the Web Publishing Rule. This dialog box will also provide you with information about the validity of the certificate, whether the certificate will expire soon, and more information. When you put a checkmark in the Show only valid certificates checkbox, you’ll only see certificates that are valid to bind to your Web listener.

In our current scenario, we’ll select the owa.msfirewall.org certificate and click Select.


Figure 11

Click Next on the Listener SSL Certificates page.


Figure 12

On the Authentication Settings page you have a number of options. However, you’ll always want to select the HTML Form Authentication option from the Select how clients will provide credentials to ISA Server drop down list when publishing OWA sites.

Note the Collect additional delegation credentials in the form option. You enable this option when using RADIUS OTP or RSA SecurID authentication.

The Select how ISA Server will validate client credentials list of options includes:

  • Windows (Active Directory) Use this option when the ISA firewall is a member of the domain. This is the most secure and flexible option
  • LDAP (Active Directory) Use this option when the ISA firewall is not a domain member, but you want to leverage Active Directory groups for access control
  • RADIUS Use this option when the ISA firewall is not a domain member, and you don’t need to leverage Active Directory groups (because you won’t be able to when using RADIUS authentication). This is the least secure and lowest performing option.
  • RADIUS OTP Use when you have a third party RADIUS one-time password solution in place.
  • RSA SecurID Use when you have deployed RSA SecurID two-factor authentication solution.

In this example, we’re using ISA firewall best practices and the ISA firewall is a domain member, so we can fully leverage the security and flexibility that domain membership provides. In this case, we’ll select the HTML Form Authentication option and the Windows (Active Directory) option and click Next.


Figure 13

Before moving to the next step, you’ll probably want to know more information about the authentication methods available and what you can do with them. The authentication method you select determines that types of authentication delegation methods available to you. The figure below provides that information. In a future article I’ll break down this table and give you some insights into what this information actually means in a production environment.


Figure 14

On the Single Sign On Settings page, put a checkmark in the Enable SSO for Web site published with this Web listener checkbox. This option enables you to publish multiple Web sites belonging to the same domain and have single sign-on for each of those sites. In contrast to ISA 2004, where you had to log into each Web site, even if they are in the same domain, when you enable SSO in ISA Server 2006, once the user has logged onto one Web site using a particular Web listener, then all other sites published with that same Web Listener will be enabled for SSO.

In this example, we’re not publishing multiple Web sites. However, if we we’re, the SSO domain would be msfirewall.org. So we’ll enable the checkbox and enter .msfirewall.org in the SSO domain name checkbox and click Next.


Figure 15

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


Figure 16

Click Next on the Select Web Listener page.


Figure 17

On the Authentication Delegation page you select how you want to delegate credentials to the published Web site. Authentication delegation enables the ISA firewall to pre-authenticate the user before forwarding the user credentials to the destination Web site. The type of delegation the ISA firewall can perform depends on how the user authenticated with the ISA firewall.

You have the following options when HTML form based authentication is used by the Web listener:

  • No delegation, and client cannot authenticate directly This option allows the ISA firewall to authenticate the user, but does not forward the use credentials to the published Web server and does not allow the client to authenticate with the Web server, even if the Web server requests authentication. Use this option when you only want the external clients to authenticate with the ISA firewall, but not the published Web server.
  • No delegation, but the client may authenticate directly This option allows the ISA firewall to authenticate the user, but the ISA firewall will not forward the credentials to the destination Web server. However, in this case, if the destination Web server challenges the client for credentials, the client will be allowed to provide these credentials.
  • Basic authentication This option allows the client to authenticate with the ISA firewall and then the ISA firewall forwards the credentials as basic authentication credentials to the destination Web server. When using this method, make sure you always deploy SSL to SSL bridging, so that the credentials are not captures on the link between the ISA firewall’s internal interface and the published Web server.
  • NTLM authentication This option allows the client to authenticate with the ISA firewall and then forward the credentials as NTLM credentials to the published Web server. This is a more secure option than basic delegation, as the actual credentials are not forwarded over the wire between the ISA firewall’s internal interface and the published Web server. However, this should be used only in circumstances where NTLM can be used at the destination Web server. In the OWA example, at this time you must use Basic authentication to authenticate with the /Exchange directory. This might change in the future, but at this time the Exchange group considered using NTLM an unsupported configuration.
  • Negotiate (Kerberos/NTLM) This option allows the client to authenticate with the ISA firewall and then negotiate Kerberos or NTLM authentication with the published Web server. The scenarios where this is applied are similar to those in the NTLM delegation scenario.
  • Kerberos constrained delegation This option allows the client to authenticate with the ISA firewall using a User Certificate. After authenticating with a User Certificate, the users’ credentials are passed as Kerberos credentials on the behalf of the ISA firewall. The ISA firewall must be configured to be trusted for delegation

In our current scenario of publishing an Exchange 2003 OWA Web site, the correct option to select is Basic authentication. The reason for this is that the Exchange team officially supports only Basic authentication to the /Exchange folder. This might change in the future, but right now we should use Basic delegation in this scenario. Select the Basic authentication option and click Next.


Figure 18

On the User Sets page, you can accept the default setting All Authenticated Users or you can create custom groups that should have access to the OWA site. In this example we’ll select the default option, but if you’re company wants to limit access to selected users, you can use the Add button to select domain Global Groups, or you can create your own custom ISA firewall Groups if you want to create custom user groups that aren’t defined in the Active Directory.

Click Next.


Figure 19

Click Finish on the Completing the New Exchange Publishing Rule Wizard page.


Figure 20

Click Apply to save the changes and update the firewall policy. Click OK in the Apply New Configuration dialog box.

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

Summary

In this part 1 of our two part series on publishing a single Exchange Server’s OWA site, we went over some the principles that underlie our publishing solution and then dove into the details of the Web Publishing Rule. In part 2 of this series we’ll look at how to customize the OWA Web Publishing Rule and how to enhance security by configuring the HTTP Security Filter to block dangerous connections that could move through an encrypted SSL tunnel. See you then! –Tom.

If you would like to be notified of when Tom Shinder releases the next part in this series please sign up to our ISAserver.org Real-Time Article Update newsletter.

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