Publishing Exchange 2007 OWA, Exchange ActiveSync and RPC/HTTP using the 2006 ISA Firewall (Part 1)

by [Published on 17 July 2007 / Last Updated on 20 May 2013]

Publishing Exchange 2007 Web services located on an Exchange Client Access Server (CAS).

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

Publishing Exchange 2007 Web services located on an Exchange Client Access Server (CAS) is relatively easy. That is to say, the ISA Firewall configuration is fairly easy. The trick is figuring out how to configure the Exchange Server to support a secure remote access scenario. Unlike Exchange Server 2003 where everything was straightforward from installation to configuration to certificate assignments, Exchange 2007 represents a convoluted and extraordinary complex installation, configuration and certificate assignment exercise. My goal is to make things a bit easier for you and help you through some of the landmines you are sure to encounter along the way.

Discuss this article

While I put many hours of research into this project in order to get things working, I have to give credit to two important resources that helped me figure out how to publish Client Access Server OWA service, Exchange ActiveSync service and the RPC/HTTP service. These resources are:

  • Exchange Server 2007 built in Help file. For the most part, the Help file was very useful in getting you up and running and walking you though many of the possible configuration landmines. However, I found it of little use in getting more advanced configuration settings working, such as remote file share access through OWA.
  • The ISA Firewall Team’s White Paper on how to publish Exchange 2007 with ISA 2006, which you can find at Publishing Exchange Server 2007 with ISA Server 2006

While these resources were very helpful in pointing me in the right direction, they certainly did not provide enough information to create a full working solution, not even a working lab environment solution. I hope that by the time you finish reading this section on how to published the Exchange 2007 Client Access Server to enable secure remote access to Exchange Web services, you will have a full working test solution and more importantly, you will understand how things work so that you will be able to customize the solution to your production needs.

The figure below shows the lab environment that we will be working with. There are several things I need to point out about this lab environment:

  • This is not the preferred configuration, nor a configuration I’d deploy in a production environment. The reason for this is that the Client Access Server should be placed on an authenticated access DMZ segment, in a security zone separate and distinct from the non-Internet facing servers. You might ask “Tom, why are you wasting my time with an unapproved scenario, why not just skip to the chase and show me how I should be publishing the Client Access Server?” The reason I have not done this yet is because I have not figured out what protocols are required between the Client Access Server and the Mailbox and Hub Transport Server. When I will figure it out, I will publish a new article. Another reason why I am publishing this information now is that many people already ignore security best practices (because the Microsoft Web site does not extol them) and so those folks will at least be able to get up to speed with the information in this section.
  • No Edge server is used in this scenario. A secure production setup would configure an edge server on anonymous access DMZ segment. Again, I do not know the protocols that the edge server needs to communicate with the Hub Transport Server, so this will have to wait for a future article for explication.
  • No dedicated hub transport server is used in this scenario. A single machine that is both a mailbox server and a Hub Transport Server is used.
  • I will not cover the procedures on how to publish the Exchange IMAP4/S or POP3/S services. There is no graphical interface for configuring these services, which represents a giant management hole in the Exchange Server. I may cover these issues in future article, but at this time, we will wait until Exchange 2007 SP1 corrects this glaring error. Let us just pray that they make certificate request and assignment for the POP3 and IMAP4 services easier than they have for Client Access Server Web services.
  • I will not cover the procedures required for publishing SMTP or SMTPS. The reason for this is that I do not yet fully understand how Exchange 2007 uses SMTP. In contrast to Exchange 2003 where you could easily configure the transparent IIS SMTP service, much of the SMTP “service” (I put “service” in quotes since there does not actually seem to be an SMTP service in Exchange 2007) in Exchange 2007 is hidden behind the PowerHell shell interface, which I try to avoid at all costs
  • I will not cover the OWA feature that enables access to network shares and SharePoint libraries. I tried to get it to work, but there must be some undocumented or underdocumented steps required to get that feature to work. This is a real shame, since I think it would be a very cool feature if it actually worked.

If you are a command line fan boy, then you are going to get irritated with my editorial comments and critiques throughout this series on how to publish the Exchange 2007 Client Access Server Web services. It is my very strong opinion that the “Microsoft Way” is to make software easy to use, and taking away management functionality that made it easy to use in previous versions is not consistent with the Microsoft Way. It is my wish that the Exchange Team will make me eat crow by including all the missing functionality in SP1. I am not happy when I have to rag on Microsoft software – I want to see it work, I want to see it be easy to configure and I want to see it get rave reviews for high functionality and ease of use. However, Exchange 2007 RTM does not meet these goals.

Now with that initial rant out of the way, take a look at the figure below again. These are all virtual machines running on VMware 5.5.


Figure 1

A short description of each machine:

  • DC This machine is the domain controller in the msfirewall.org domain. All machines in this scenario are part of the msfirewall.org domain. In addition to performing the role of domain controller, this machine is also a DHCP server, an Active Directory integrated DNS server, a WINS server, a Microsoft Certificate Server and a RADIUS server. RADIUS is not used in the scenario discussed in this section, though.
  • EXCH2007MB This is a Windows Server 2003 SP2 machine that is configured with the Exchange 2007 Mailbox Server and Hub Transport Server roles. No services other than those required by the Exchange Server setup are installed on this machine.
  • EXCH2007CAS This is a Windows Server 2003 SP2 machine that is configured with the Exchange 2007 Client Access Server role. No services other than those called out during the installation of Exchange are installed.
  • ISA2006SE This is a Windows Server 2003 SP2 machine that has ISA 2006 Standard Edition installed on it. All updates available on Microsoft Update are installed on this machine. This is important because there is a critical update for ISA 2006 that is required to publish Exchange Web services. This update will be available from the Microsoft Update site and will appear as an ISA Server update. Also, the RSS fix was applied to this machine, just in case this might be an issue. You can find details of the RRS fix at ISA Server Product Team Blog
  • VISTA This is a Vista RTM machine. I actually agonized on whether I should use a Vista or Windows XP SP2 machine for this example. But I figured that if there are going to be configuration challenges and problems, they will more likely appear in Vista than in Windows XP SP2, so I decided to go with Vista to see what problems might come up.

To help you get your lab up to speed, I have included the table below which summarizes the important aspects of the machine configuration for each of the VMs in this scenario.

 

DC

EXCH2007MB

EXCH2007CAS

ISA2006SE

VISTA

OS

Windows Server 2003 Enterprise Edition SP2

Windows Server 2003 Enterprise Edition SP2

Windows Server 2003 Enterprise Edition SP2

Windows Server 2003 Enterprise Edition SP2

Vista RTM

IP Addressing Information

IP address:

10.0.0.2

DG:

10.0.0.1

DNS:

10.0.0.2

IP address:

10.0.0.4

DG:

10.0.0.1

DNS:

10.0.0.2

IP address:

10.0.0.5

DG:

10.0.0.1

DNS:

10.0.0.2

Internal:

IP address:

10.0.0.1

DNS:

10.0.0.2

External:

IP address:

192.168.1.71

DG:

192.168.1.60

DHCP

Installed Services

DHCP

WINS

DNS

Certificate Services

RADIUS

(All updates from Microsoft Update installed)

None

(all services are installed after Exchange installation begins)

(All updates from Microsoft Update installed)

None

(all services are installed after Exchange installation begins)

(All updates from Microsoft Update installed)

ISA 2006 Standard Edition

(All updates from Microsoft update installed)

None

(All updates from Microsoft Update installed)

Domain Member?

YES

YES

YES

YES

YES

Domain Name

msfirewall.org

msfirewall.org

msfirewall.org

msfirewall.org

msfirewall.org

Exchange Server Role

N/A

Mailbox server

Hub Transport

Client Access Server

N/A

N/A

VMNet

2

2

2

Ext: Bridged

Int: 2

When Ext: Bridged

When Int: 2

Table 1: Virtual Machine Configurations for Test Lab

I should mention here that you will need to have your ISA Firewall fully installed and configured prior to installing the Exchange Servers. The reason for this is that you will need Internet access to download all the pre-requisite files that were not included on the Exchange Server DVD. I just created a single Access Rule that allowed outbound access for all protocols from the default Internal Network to the default External Network. However, if you wanted to lock things down, you would allow outbound DNS from the DC machine, and outbound HTTP and HTTPS from the EXCH2007MB and EXCH2007CAS machines. You should be able to download updates from the Windows Update site for the ISA Firewall using the default System Policy Rules, so no changes need to be made on the ISA Firewall to support updates. All machines on the network are configured as SecureNET clients.

The following represents the general procedures that we will perform on the machines in this scenario:

  • Configure DNS to support roaming users.
  • Install the Exchange 2007 Mailbox Server and Hub Transport Server roles on the EXCH2007MB machine. We will go through the procedures for installing the Mailbox and Hub Transport Server roles. It is not as easy as you think!
  • Configure the Exchange 2007 Mailbox Server and Hub Transport Server machine based on the built in Help information. After installing the Exchange Mailbox and Hub Transport Server roles, we will walk through the built-in Help guidance for performing initial configuration settings. We wll also turn off the new “backpressure” feature so that things work right in a VM.
  • Install the Exchange 2007 Client Access Server on the EXCH2007CAS machine. We will go through the procedures required to install the Client Access Server on this machine. Again, it will not be as easy as you think!
  • Configure the Exchange 2007 Client Access Server based on the built in Help information. We will walk through the procedures described in the built-in Help guidance for the Client Access Server role.
  • Perform additional configuration steps on the Exchange 2007 Client Access Server machine, including certificate request, certificate installation, permissions configuration, RPC/HTTP configuration and others. There are a number of settings we will have to make here to get our final solution working, and not all of them are documented!
  • Configure the Outlook 2007 client. Configurating the Outlook 2007 client is very similar to configurating the Outlook 2003 client. However, in this scenario I am not configuring Exchange with special folders that only Outlook 2007 can use.

Finally, I need to point out that I am using the 32-bit trial version of Exchange. The reason for this is that while VMware does support running 64-bit guests on 32-bit host operating systems, the processor, if Intel, must be VT-enabled. That means your processor must be Pentium D series 900 or newer to do this. Unfortunately, mine is a Pentium D 820.

Discuss this article

WARNING: The Exchange Publishing Nightmare Scenario

Before we move on to DNS considerations for our design, I should point out a deployment scenario that you should never use, something I call the Exchange Publishing Nightmare Scenario. The figure below shows the topology for the Exchange Publishing Nightmare scenario.


Figure 2

In the Exchange Publishing Nightmare Scenario the ISA Firewall is separated from the internal network by a third party firewall. As seen in the figure below, there are two “hardware” firewalls deployed, one on the edge of the corporate network and a backend firewall in front of the corpnet. A DMZ segment is seen on the back end “hardware” firewall where a single NIC “hork mode” ISA Firewall is deployed. There are several serious defects in this design:

  • The back-end “hardware” firewall represents unnecessary point of failure
  • The back-end “hardware” firewall represents another opportunity for firewall misconfiguration – the most common cause of firewall related security issues
  • The ISA Firewall is subjected to the security weaknesses of the back-end “hardware” firewall. A quick look at www.secunia.com shows that the ISA Firewall (2004 and 2006) have no active security issues. Compare this with any “hardware” firewall and you will see that the ISA Firewall is more secure than just about any hardware firewall

A variant of this Exchange Publishing Nightmare Scenario places a hork mode ISA Firewall in the DMZ between the “hardware” firewalls, something that I refer to as the “hork mode sandwich”. The problem in “hork mode sandwich” and the scenario depicted in the graphic is that the full firewall feature set is gutted from the ISA Firewall when deployed in hork mode. There is no technical reason for this type of deployment. The only reasons for such a deployment would be political or ignorance. If you need or want to use a back to back Firewall deployment, then place the ISA Firewall closest to the resources that need protection, as the most secure firewall should be nearest the protected resource, and the ISA Firewall is most likely the most secure firewall in this scenario.

Configure DNS to Support Roaming Users

Most companies have users who move in and out of the corporate network using the same computing devices, which in most cases is a laptop. These users should be able to reach the OWA and RPC/HTTP sites, as well as the ActiveSync site, without having to reconfigure their devices to use an alternate name. We can do this by using a split DNS infrastructure. When you deploy a split DNS infrastructure, access to these sites is transparent to the users; they never have to reconfigure their client applications to reach the information they need.

To solve this problem, we use a split DNS. In a split DNS, the same domain name is hosted on two different DNS servers containing two different DNS zones. There are usually two zones: an external zone that services external network clients and an internal zone that services internal network clients. Clients resolves names based on which zone they are located at that time.

External zone users will resolve the owa.msfirewall.org to the address on the external interface that we will use for the Web Listener in our Exchange Web services publishing rules. Internal users will resolve the name owa.msfirewall.org to the IP address on the internal interface of the ISA Firewall that will be used by the Web Listener used for the Exchange Web services publishing rules.

This is a bit of a departure from my usual recommendations, as I typically use the split DNS to allow internal users to connect directly to the Client Access Server and bypass the ISA Firewall. While this is a valid configuration for a split DNS, the problem we run into is that Internal users who connect directly to the Exchange Client Access Server will  not benefit from forms-based authentication and ISA Firewall security.

The reason why internal users who connect directly to the Client Access Server will not benefit from forms-based authentication is that we need to turn off forms-based authentication on the Exchange Client Access Server when publishing the Client Access Server using the ISA Firewall. Instead, users use the ISA Firewall’s forms-based authentication. In addition, if users connect directly to the Exchange Server, they can bypass the security controls implemented on the ISA Firewall. Thus for these two reasons I have backed down on the “looping back” through the ISA Firewall aversion.

Our example network uses what I call an “integrated” split DNS infrastructure. In an integrated split DNS infrastructure, the actual Active Directory domain name is the same as the external domain name that users will use to connect to the Exchange Client Access Server resources. In many cases this is not possible because the company has already deployed Active Directory and the domain name is either not available (because someone else has registered their domain name for Internet use) or they have standardized on an illegal top level domain name.

We can solve these problems by using what I call a “parallel” split DNS. In a parallel split DNS the DNS zone names are different from the actual Active Directory domain name. This is easy to set up, as you only need to create a new zone name that you will use for your roaming users and create zones for internal network users and external network users on two separate DNS servers.

The figure below shows the sequence of events for both internal and external clients.


Figure 3

For an internal client, the following events take place:

  1. An internal client makes a DNS query request for owa.msfirewall.org to the internal network DNS server.
  2. The internal DNS server authoritative for the msfirewall.org domain returns the IP address 10.0.0.1 for the name owa.msfirewall.org
  3. The internal client sends a request for owa.msfirewall.org/OWA to the IP address on the internal interface of the ISA Firewall (10.0.0.1).
  4. The ISA Firewall authenticates, authorizes and inspections the connection and then forwards it to the Exchange Client Access Server.
  5. The Exchange Client Access Server returns data to the ISA Firewall’s internal interface; the ISA Firewall inspects the response
  6. The ISA Firewall returns the data to the client making the request

For an external client, the following events take place:

  1. The external client makes a DNS query request to an external DNS server that is authoritative for the msfirewall.org domain.
  2. The external DNS server returns to the client the IP address on the external interface of the ISA Firewall that is used by the Web Listener for the Exchange Web service publishing rules.
  3. The external client sends a request for owa.msfirewall.org/OWA to the IP address on the external interface of the ISA Firewall.
  4. The ISA Firewall authenticates, authorizes, and inspects the connection and then forwards the request to the Exchange Client Access Server.
  5. The Exchange Client Access Server returns the response to the ISA Firewall.
  6. The ISA Firewall inspects the response and then forwards it to the external client that made the request.

For more information on creating a split DNS, integrated split DNS and parallel split DNS, see the following articles:

http://isaserver.org/tutorials/You_Need_to_Create_a_Split_DNS.html
http://isaserver.org/tutorials/2004illegaltldsplitdns.html

For our current scenario, we need to create a Host (A) record for owa.msfirewall.org on our internal and external DNS servers. We will cover only the internal DNS server in this example, as you likely will be using a non-Windows based DNS server for your external zone.

Open the DNS console by clicking the link in the Administrative Tools menu. In the DNS console, expand the Forward Lookup Zones node and click on the msfirewall.org zone. Right click in an empty area in the right pane and click the New Host (A) command.


Figure 4

In the New Host dialog box, enter the name owa in the Name (uses parent domain name if blank) test box. Enter the internal IP address on the ISA Firewall in the IP address text box. If you created a reverse lookup zone for your internal network, put a checkmark in the Create associated pointer (PTR) record (I have already created a reverse lookup zone for the internal network on this DNS server). Click Add Host.


Figure 5

The new record is created. Click Done in the New Host dialog box. You can now see the new resource record in the middle pane of the DNS console. Restart the DNS service after the record is created.


Figure 6

Discuss this article

Summary

In this first part of our series on how to publish Exchange 2007 Web services using ISA 2006 firewalls, we went over the example network configuration and details of the lab topology that we will be using for the rest of the article series. In this article we made specific emphasis that the design discussed in this series does not provide the highest level of security, but that this topology is often used in production because of its relative ease of use. We also made special mention of the Exchange Publishing Nightmare Scenario where ISA Firewall security is subverted by using extraneous firewalls and deploying the ISA Firewall in “hork mode”. Important DNS considerations were discussed with special focus on a split DNS infrastructure. Next week we will start installing Exchange 2007, which is a real adventure in itself! See you then. –Tom.

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

Advertisement

Featured Links