Don't put CAS in the Perimeter network!

[The_Exchange_Team]

We sometimes hear customers talking about locating Exchange 2007 or Exchange 2010 Client Access Servers (CAS) on the perimeter network (also known as the "DMZ" - Demilitarized Zone). A perimeter network is a network zone many companies deploy between the Internet and their intranet as defense-in-depth. The idea behind a perimeter network is to add additional steps to what a hacker would have to do to get access to any intranet resources. To add as strong defense-in-depth as possible, you want to put only servers you trust to withstand Internet attacks in the perimeter, and then you should assume they can be broken into anyway.

With Exchange 2000/2003, it was supported and there was documentation explaining how to put an Exchange 2000/2003 Front-End (FE) server into the perimeter network, with a firewall between the FE and the Back-End (BE) servers it accessed. This leads some customers who upgrade from Exchange 2000/E2003 to expect the same deployment pattern with Exchange 2007/2010.

As you start planning for deploying an Exchange 2007/2010 CAS server in the perimeter network, you quickly notice that there's no documentation for how to do this though. You'll probably even find the TechNet documentation which explains this is explicitly not supported by Microsoft. Microsoft doesn't test or support any topologies which put firewalls between a CAS and a Mailbox (MBX) server. The only Exchange 2007/2010 role which is supported for deployment in a perimeter network, and with a firewall server separating it from other Exchange server it talks to, is the Edge Transport server role. This is true for Exchange servers talking to one another within and between Active Directory Sites.

The fact that there is no support for using firewalls between Exchange servers (except for the Edge Transport server role) sometimes causes confusion for how to use the Windows Server Firewall with Advanced Security on Exchange 2007/2007 servers. It's supported to have the Windows OS firewall turned on for Exchange servers. In fact, we strongly recommend you leave the Windows OS firewall turned on as a defense-in-depth measure. Exchange 2010 setup is smart enough to configure the Windows OS firewall so it'll let through all Exchange traffic appropriately. Note, for Exchange 2007 you need to run the Security Configuration Wizard and apply the Exchange 2007 role-based template. Detailed instructions can be found in Using the Security Configuration Wizard (SCW) to Secure Windows for Exchange Server Roles in Exchange 2007 docs.

Note: In Exchange 2010, it's not required to use the Security Configuration Wizard to open the necessary ports for the Exchange 2010 server role and services running on a server. The configuration steps are included in Exchange 2010 Setup, and we don't ship any SCW templates for Exchange 2010.

Understanding the reasons why we don't support CAS in the perimeter

When discussing the fact that it's not supported to put CAS in the perimeter network, the next question is obviously "why?". If this was supported and documented for Exchange 2000/2003 Front-End servers, why not for Exchange 2007/2010 CAS?

The most important reason why customers wanted to install Exchange FE servers in the perimeter network was to block any unauthenticated traffic from reaching servers on the intranet. This is a good practice, but as you'll see below doing this with Exchange FE/CAS servers is no longer the best way to accomplish this goal.

It is important to understand that the CAS role in Exchange 2007/2010 is significantly different from the FE server in Exchange 2000/2003.

The Exchange 2000/E2003 FE servers were there to authenticate users and proxy traffic to the BE server where the traffic was actually interpreted and responded to. For example, the FE servers in Exchange 2000/2003 don't do any Outlook Web Access (OWA) rendering. That all takes place on the BE servers. The Exchange 2007/E2010 CAS role on the other hand contains all middle-tier logic and rendering code for processes like OWA, Exchange ActiveSync (EAS), Exchange Web Services (EWS), and more.

In the same timeframe as Exchange 2007 was available, enough customers had also started using reverse proxies (e.g. Internet Security and Acceleration server (ISA) 2000 FP1, 2004 or 2006) with functionality like pre-authentication. This meant there was now a good way to do authentication of Exchange traffic before it reached the Exchange servers. The role the Exchange 2000/E2003 FE server had played for defense-in-depth by pre-authenticating traffic before it reached servers, which included a lot of Exchange business logic, could now be better handled by these new reverse proxies. The reasons a reverse proxy like this does a better job than an Exchange FE or CAS server for this defense-in-depth role are:

• Exchange CAS servers require full access to all mailboxes in an AD Site, and significant access rights to the AD. That's a level of access privileged which you should avoid having in the perimeter network.
• The Exchange FE executed a little bit of Exchange business logic, and the Exchange CAS executes a lot of Exchange business logic. The more business logic you expose in the perimeter network, the more risk you're taking that something in that logic can be hacked. For servers you put in the perimeter network, you want to minimize the logic/code surface area they run and which is exposed to attack from the outside. Reverse Proxies are built with the primary purpose of withstanding Internet attacks like that. Although Exchange servers are also hardened from a security perspective, they run much more logic than a reverse proxy, which increases the risk.
• Reverse Proxies are built to be put in the perimeter network or at the edge of the network. They include many security features and flexibility for customers to determine the level of defense-in-depth which is right in any particular environment. Some of these defense-in-depth features are easy to just turn on (e.g. using pre-authentication while your reverse proxy is an Active Directory domain member; or avoiding Active Directory domain membership and limiting pre-authentication capabilities), whereas other defense-in-depth features take more work (e.g. using pre-authentication without domain membership by using RADIUS). But the important distinction between the reverse proxies and the CAS is that the reverse proxies have many more defense-in-depth features and deployment models available than Exchange CAS.

In addition to these reasons why a reverse proxy does a better job in the perimeter network than an Exchange FE/CAS does, there's also a problem with FE/CAS in the perimeter which goes away when using a reverse proxy there instead:

• Deploying an E2000/E2003 FE server in the Perimeter network was difficult. The port settings and other internal firewall configuration required was complicated and many customers ran into problems setting this up correctly. Different types of internal firewalls required different configuration and the symptoms experienced by Internet clients when something was misconfigured weren't always easy to diagnose. This complexity and the errors it caused was a problem for Exchange customers. The internal firewall configuration required when using a reverse proxy in the perimeter is much simpler. This is why we don't offer "CAS in the perimeter network" as a supported solution even for customers who want to take the security risks listed above: people accidentally end up shooting themselves in the foot when trying to configure things for a FE/CAS to work in a perimeter network.

  If you are curious, the ports used between server roles by E2007 are listed in Exchange Network Port Reference.

Conclusion

The best way to deploy Exchange CAS with respect to a perimeter network is to put a reverse proxy you trust in the perimeter, configure the firewall between the perimeter and the intranet to be as restrictive as possible and to host the CAS server on the intranet. This will get traffic inspection and other reverse proxy security filtering in place in the perimeter.
As extra defense, you can also configure pre-authentication to be done on the reverse proxy. This might not be possible for all Exchange protocols if you want to expose some advanced functionality like Exchange 2010 Federated Free/Busy and Calendar Sharing to the Internet (see Understanding Federation and Understanding Federated Delegation for details about these features). But you can configure the pre-authentication for as many clients and protocols as is supported by the reverse proxy and the scenarios you want to enable.

Regards,

Kristian Andaker, Jason Henderson