Publishing Outlook Web Access and Outlook RPC/HTTP with ISA Server 2006 Enterprise Edition Firewalls using Forms-based Authentication (Single Member Array without NLB)

Publishing Outlook Web Access and Outlook RPC/HTTP with ISA Server 2006 Enterprise Edition Firewalls using Forms-based Authentication (Single Member Array without NLB)
By Thomas W Shinder MD, MVP


 

If you would like to read the other parts in this article series please go to:

ISA Server 2006 is a multifunction universal threat management (UTM) device that includes an enterprise-grade firewall, remote access VPN server, site to site VPN gateway and Web proxy and caching server. The ISA firewall can be configured to act in a single role or in any combination of these roles. Regardless of your deployment scenario, the ISA firewall always enforces stateful packet and application layer inspection for all communications moving through the firewall.

The key deployment scenario for ISA firewalls in an enterprise environment is for secure remote access to Microsoft Exchange Server Web services. These Web services include:

  • Outlook Web Access (OWA)
  • Outlook Mobile Access (OMA – scheduled for retirement and not included in Exchange 2007)
  • Exchange ActiveSync (EAS – for Windows Mobile enabled phones and pocket PCs)
  • Outlook RPC/HTTP (supports Outlook MAPI connections using SSL secured HTTP as the application layer transport)

In this article we’ll focus on the following:

  • Deployment of a single ISA Server 2006 Enterprise Edition firewall in a single member array joined to the domain
  • A single IP address on the external interface of the ISA firewall
  • A single Web listener to support both OWA publishing using forms-based authentication and RPC/HTTP

I will not discuss issues with Windows Mobile at this time.

ISA Server 2006 includes a new feature that enables you to publish OWA Web sites using forms-based authentication while still being able to use the same Web listener to publish applications that do not support forms-based authentication (FBA). The primary use case scenario for this new feature is RPC/HTTP. In ISA 2004 you could not use the same Web listener for OWA/FBA and RPC/HTTP publishing because the Outlook 2003 client did not know how to handle the form. This required you to have two different Web listeners, two different certificates and two IP addresses to publish both OWA/FBA and RPC/HTTP.

The ISA Server 2006 solution to this problem is to inspect the client agent header in the request. If the client agent is not a Web browser, then the ISA firewall is able to fall back on another authentication mechanism. In the case of RPC/HTTP, the fallback authentication mechanism is basic authentication, which is the preferred authentication mechanism for Outlook RPC/HTTP clients over a secure SSL connection. This article will focus on this new capability.

In this article we’ll discuss the lab environment and provide some background on supporting networking services. In the next article we’ll look into DNS and certificate deployment issues and begin the ISA firewall configuration.

Describing the Lab Environment

The figure below provides a high level overview of the lab environment. All machines are located on the same network segment and thus represent the same security zone. In a production environment this might be a network services segment or even an authenticated access DMZ, although the DC would not be located on the authenticated access DMZ. The point is that there are many possible network topologies for secure OWA and RPC/HTTP publishing.

One important consideration in a secure Exchange Web services publishing scenario is that ideally you will have three IP address and three different URLs to support publishing of OWA, ActiveSync/OMA and RPC/HTTP. The reason for this is that the HTTP Security Filter configuration for each of these Web services is slightly different, and a secure configuration enables you to customize the HTTP Security Filter for each Web Publishing Rule. In order to support this highly secure configuration, you need at least three IP addresses bound to the external interface of the ISA firewall. However, with that said, HTTP Security Filter configuration is done on a per-rule basis, so you could potentially do this by creating three different rules. I’ll discuss the issues in a later article to show why you might want to deploy this alternate configuration.

However, in this article I want to demonstrate the new ISA Server 2006 feature that enables you to use the same Web listener for OWA/FBA and RPC/HTTP, which means we only need a single IP address on the external interface of the ISA firewall to support the configuration. In addition, I’ll take this opportunity to demonstrate the new ISA Server 2006 feature called Web farm load balancing that provides load balancing and transparent failover and failback for published Web farms, such as a collection of front-end Exchange Servers.

In this lab I’ll use a single network segment for all the services as a lab convenience only. However, many Exchange administrators may prefer this topology because it’s easier to implement and doesn’t require that you have a good understanding of the ISA firewall’s multinetworking capabilities. In addition, the Microsoft Exchange Server team seems to think that this is a secure enough configuration and is the model they use in the majority of their documentation that includes discussions of the ISA firewall.

If you are interested in a more secure configuration and the one that I and other network security experts prefer, check out: http://www.isaserver.org/tutorials/Configuring-Domain-Members-Back-to-Back-ISA-Firewall-DMZ-Part1.html

NOTE:
In future articles I’ll describe how to implement the highly secure configuration where you use three IP address, three Web listeners, and three different Web Publishing Rules to support the best level of security for publishing Exchange Web services.


Figure 1

Table 1 provides key information about the configuration of each of the machines in the lab.

Machine name

DC

BEEXCAHNGE2003

FE1EXCHANGE

FE2EXCHANGE

ISA2006SE**

IP addressing information

IP address: 10.0.0.2/24

Default gateway: 10.0.0.1

DNS: 10.0.0.2

IP address: 10.0.0.3/24

Default gateway: 10.0.0.1

DNS: 10.0.0.2

IP address: 10.0.0.4/24

Default gateway: 10.0.0.1

DNS: 10.0.0.2

IP address: 10.0.0.5/24

Default gateway: 10.0.0.1

DNS: 10.0.0.2

EXT IP address: 192.168.1.71/24

Default gateway: 192.168.1.60/24

INT IP address: 10.0.0.1/24

DNS: 10.0.0.2*

OS

Windows Server 2003 SP1

Windows Server 2003 SP1

Windows Server 2003 SP1

Windows Server 2003 SP1

Windows Server 2003 SP1

Network Services Installed

DHCP

DNS

Enterprise CA

IAS

WINS

Active Directory

CMAK

Microsoft Exchange Server 2003 SP2

Configured as back-end Exchange Server

Microsoft Exchange Server SP2

Configured as the first of a pair of front-end Exchange Servers

Microsoft Exchange Server SP2

Configured as the second of a pair of front-end Exchange Servers

ISA Server 2006 Enterprise Edition as a single member array

CSS installed on firewall

Member of user domain (recommended configuration)

Certificates installed

CA certificate for enterprise CA installed on the DC

CA certificate for enterprise CA installed on the DC

CA certificate for enterprise CA installed on the DC

Web site certificate with common/subject name owa.msfirewall.org installed on the default Web site

CA certificate for enterprise CA installed on the DC

Web site certificate with common/subject name owa.msfirewall.org installed on the default Web site

CA certificate for Enterprise CA

Web site certificate with common/subject name owa.msfirewall.org installed in machine certificate store to be used by Web listener

Notes:

DC is the domain controller on this network where all machines are members of the msfirewall.org domain.

All supporting networking services required by the ISA firewall are installed on DC.

This is not meant to represent a recommended or highly secure configuration. For example, DHCP servers are best located on a machine that is not a DC.

Some services, such as the CMAK and IAS are installed to support configurations that are not discussed in this article.

BEEXCHANGE2003 is a back-end Exchange Server in the same domain as all other servers in the domain.

This back-end Exchange Server will be the back-end for two front-end Exchange Servers.

Note that this isn’t meant to promote a preferred configuration. Depending on the number of mailboxes, two or more back-end Exchange Servers may be required.

FE1EXCHANGE is a first of two front-end Exchange Servers.

This machine hosts OWA front-end and the RPC/HTTP proxy sites.

FE1EXCHANGE is a first of two front-end Exchange Servers.

This machine hosts OWA front-end and the RPC/HTTP proxy sites.

* It is critical that a single DNS server address is configured on the ISA firewall and that DNS server address is configured only on the internal interface of the ISA firewall and that interface should be on the top of the interface list.

**The name of the server seems to indicate that this is Standard Edition firewall, but it’s a lab artifact. In this lab the ISA2006SE machine has ISA Server 2006 Enterprise Edition installed.

The ISA firewall is a domain member, which in general is a more secure configuration. Certain features included in ISA Server 2006 mitigate the lower security posture of a non-domain member, but not completely.

Note the default gateway in this lab is for the internal address of an upstream ISA firewall. This is an artifact of my lab configuration. You should configure your default gateway as appropriate first for your lab environment and then your production environment.

Table 1: Configuration Information for Lab Machines

DC has a number of networking services installed on it that are used to support the ISA firewall configuration for a number of different scenarios. One of the most commonly ignored issues in ISA firewall planning and deployment is installing and configuring these supporting network services before the ISA firewall is installed and configured.

These networking services include:

  • DHCP
    In ISA firewall deployments DHCP provides support for IP addressing information for remote access VPN clients and site to site VPN gateways. While DHCP is not required in these scenarios, you can greatly simplify your deployments by using DHCP for VPN client and gateway addressing. We will not be using DHCP services in this article, but will use them in future articles on ISA Server 2006 VPN remote access VPN server and VPN gateway configurations.
  • DNS
    DNS is a critical networking service on which the ISA firewall depends heavily. The ISA firewall uses DNS to perform forward and reverse lookup for outbound requests, inbound requests, and for locating its domain controller. The DNS infrastructure must be established and correctly configured before the ISA firewall is deployed.
  • IAS (RADIUS)
    The ISA firewall can be configured to use RADIUS authentication for inbound and outbound Web connections made through the ISA firewall’s Web proxy filter. In addition, the ISA firewall can use RADIUS authentication for remote access VPN and site to site VPN gateway configurations. We will not be using RADIUS authentication in this article but the service is installed in order to support RADIUS authentication in future articles.
  • Certificate Services
    Certificate services is a core component of any secure Exchange publishing scenario using ISA firewalls. The ISA firewall uses certificate services to support secure Web publishing by impersonating the published servers. The Web servers must have Web site certificates installed so that the ISA firewall can provide secure SSL to SSL bridging. These Web site certificates are exported, along with their private keys, and installed in the ISA firewall’s machine certificate store. This enables the ISA firewall to use these certificates in Web listeners used in Web Publishing Rules that publish the secure Exchange Web services.
  • WINS
    WINS provides name resolution support for NetBIOS (computer) names. Users at many companies are accustomed to connecting to corporate resources using a computer name instead of a fully qualified domain name. The problem is that no user machines are configured to correctly qualify an unqualified request and thus need to be able to fail back on NetBIOS name resolution. WINS is more important when you plan to deploy the ISA firewall as a remote access VPN server solution. WINS does not play a role in the deployment scenario discussed in this article series.
  • CMAK
    The CMAK (Connection Manager Administration Kit) is used to create VPN client packages that users can install with a click of the mouse. The CMAK packages can be emailed to users or you can instruct them to download the CMAK VPN client package from a Web or FTP site. The CMAK package can be configured to provide specific security settings that you need to meet the security requirements of your organization. The CMAK is used to support the ISA firewall when its configured as a remote access VPN server. The CMAK does not apply to the current scenarios.





BEEXCHANGE2003 has Exchange 2003 SP2 installed on a base of Windows Server 2003 operating system. This machine is configured as a back-end Exchange Server and is a member of the msfirewall.org domain, as are all other machines in this lab.

The FE1EXCHANGE and FE2EXCHANGE machines are configured as front-end Exchange Servers to the BEEXCHANGE2003 machine. These machines have the RPC/HTTP proxy installed on them so that they can act as RPC proxy for Outlook 2003 clients. The front-end Exchange Servers belong to the msfirewall.org domain as are all other machines in this lab. A Web site certificate is bound to the default Web site on both of these machines using the common/subject name owa.msfirewall.org.

The ISA2006SE machine is configured in full firewall mode with an external interface connected to an external network and an internal interface connected to an internal network. The ISA firewall is configured as a single member array machine using ISA Server 2006 Enterprise Edition. Because this is a single member array, an intra-array network interface is not required. Had I configured the machine as a member of a multiple machine array, then each machine should have three interfaces installed so that the third interface can be provisioned as an intra-array NIC.

The ISA firewall is configured as a domain member to enhance the overall security the firewall can provide the network. If the ISA firewall we’re not a member of the domain, we could not leverage transparent authentication for Web proxy and Firewall clients. In fact, we could not use the Firewall client at all which severely limits the number of protocols we can use for outbound access. We also wouldn’t be able to obtain information about the applications that users use to access the Internet without Firewall client support.

NOTE:
It’s not entirely accurate to say that the Firewall client is not supported when the ISA firewall is not a member of the user domain. You could use the Firewall client if you mirrored user accounts on the ISA firewall. The mirrored accounts would need to have the same username and password as the user’s domain accounts. This isn’t a realistic scenario in an enterprise environment because this configuration is not very scalable.

We also want the ISA firewall to perform delegation of basic authentication, which allows the ISA firewall to pre-authenticate users and transparently pass those credentials to the front-end Exchange Servers. With delegation of basic authentication, the ISA firewall first authenticates and authorizes the user’s connection. If the user successfully authenticates and is authorized to connect to the OWA or RPC/HTTP sites, then the ISA firewall will forward those credentials to the front-end Exchange Servers so that the user doesn’t have to authenticate a second time.

Summary

ISA Server 2006 is a firewall, remote access VPN server, site to site VPN gateway and Web proxy and caching solution. One of the key deployment scenarios for the ISA firewall is to provide secure remote access to Microsoft Exchange Web services by acting as a reverse proxy server. The ISA firewall comes, right out the box, with a number of technologies and wizards that enable you to create secure Web Publishing Rules with a minimum of effort and get them right every time.

In this article series we’ll discuss the concepts, principles and practices of publishing the OWA and RPC/HTTP Web sites using an ISA firewall with a single external IP address. While there are many possible topologies and configurations I could have chosen from, I decided to choose this one as my first Web Publishing article for ISA Server 2006 because it provides an opportunity to introduce a new feature that allows you to publish the OWA and RPC/HTTP sites using a single IP address, something that wasn’t possible with ISA 2004.

In the next article in this series I’ll discuss the DNS and certificate issues in this configuration. The DNS issues are critically important and are very often misunderstood and lead to failed deployments that would otherwise be successful. I’ll also discuss the certificate deployment and naming conventions that are tightly integrated with DNS name resolution settings. See you then! –Tom.

If you would like to read the other parts in this article series please go to:

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