Exchange Server 2010 : Positioning the Client Access Server in Your LAN (part 1) - Client Access Server Proxying

After you complete your design for the hardware on which the Client Access server role will run, the next step to consider is the positioning of the Client Access server role in your LAN. As a bare minimum, every Active Directory site hosting a Mailbox server also requires a CAS.

As with Exchange Server 2007, you want to avoid placing your Exchange Server 2010 Client Access servers in your perimeter network. This is important because the CAS uses RPCs to connect to the Mailbox server role. Because of this, the number of ports you must open to provide access for your CAS leaves a rather large hole for potential attack. You can either publish a CAS directly to Internet clients or you can use a reverse proxy to provide an additional layer of protection. We strongly urge you to put your Client Access servers on your internal network and use a reverse proxy to publish the servers to the Internet.

So what are you expected to do? Our recommendation is to place the Client Access server role on your internal LAN and then proxy connections to it using a reverse proxy server like ISA Server 2006 or Microsoft's successor, Forefront Threat Management Gateway (TMG). This gives you many benefits, not the least of which is that the only thing being exposed directly to Internet traffic is the proxy/firewall—which is designed specifically for that exposure. When using ISA or TMG, you also get the benefit of preauthentication, which ensures that only authenticated traffic gets through to your internal LAN. On top of this, all inbound connection requests are inspected to ensure they are valid. This makes things even more secure by closely checking all traffic to your Client Access servers for potential HTML exploits and nonstandard HTML requests before passing it through to your LAN.

1. Client Access Server Proxying

Let's take a more detailed look at how remote access works and, more specifically, how your placement of Client Access servers and Internet connections affects what happens.

First, you need to understand how Client Access servers talk to Mailbox servers when users try to access their mailboxes. If you have a single Active Directory site (Baltimore) with Exchange servers in it, then you have a fairly simple scenario, as shown in Figure 1. You would provide remote access via a reverse proxy or some other type of firewall. In this scenario, the user talks to the CAS (either directly or through the firewall) and the CAS talks to the Mailbox server.

Figure 1. A simple single-site Exchange setup

So what about when you introduce another Active Directory site (Honolulu) with Mailbox and Client Access servers? It depends. Let's look at a situation where a user, Nora, has her mailbox on a Mailbox server in Honolulu. If Nora were to use Outlook Web App to access the CAS in Baltimore (CAS-1), the server would look up Nora's mailbox location in Active Directory and find that her mailbox is actually hosted on a Mailbox server in Honolulu (MB-2).

At this point, the CAS in Baltimore (CAS-1) will determine if an external URL is configured for the CAS in Honolulu (CAS-2). If not, CAS-1 will contact CAS-2 and then proxy Nora's request to it. CAS-2 gets the info from Nora's Mailbox server and passes it back to CAS-1. From there the information is returned to Nora. So proxying is nothing more than one CAS telling another CAS to access the user's mailbox because it can't contact the Mailbox server itself. As shown in Figure 2, the cross-site traffic between Client Access servers uses HTTPS, and not RPC. HTTPS is better to use than RPC for long-distance connections that are unreliable and susceptible to network latency.

Figure 2. A simple CAS proxy scenario

When designing your Exchange topology to include Client Access servers, keep in mind that proxying only works in a point-to-point fashion between the requesting CAS and a CAS in the same site as the Mailbox server. If firewalls are in place that prevents this traffic, the CAS will not negotiate a hop-to-hop route via another site where there is connectivity.

In previous versions of Exchange, there were a couple of cases where proxying could not be used: when connecting via IMAP or POP3. However, Exchange 2010 now provides support for IMAP and POP3 proxying. Client Access servers are configured for proxying IMAP and POP3 by default. Proxying only works for virtual directories configured for Integrated Windows authentication, which means if you want Forms-based authentication (FBA) or Basic Authentication to be used internally, you will need to configure a separate Outlook Web App virtual directory for use when inside your network.

To provide a better understanding of proxying, we want to introduce you to two important parameters. The InternalURL and ExternalURL parameters can be specified on web-accessible virtual directories, such as Outlook Web App, the Exchange Control Panel, Exchange ActiveSync, and the Offline Address Book distribution web service. These parameters define how the CAS performs proxying and redirection. In many cases, Client Access servers that are Internet facing should have their public, Internet-accessible URL in the ExternalURL parameter for the web services that are accessible over the Internet, such as Outlook Web App or Exchange ActiveSync. For example, this URL could be https://webmail.domain.com/owa. If you don't specify an ExternalURL for your Internet-facing servers, those servers won't be used for client redirection. If you are using a single-site configuration, you don't need the ExternalURL specified for OWA. However, if you want to take advantage of using Autodiscover for external client configuration, you will still need to configure ExternalURL for Exchange ActiveSync, Offline Address Book distribution, and Exchange Web Services.

In the InternalURL parameter, the CAS should have the URL that users inside the network will use to access it. This is important, because when a Client Access server (CAS-1) realizes that the mailbox it's looking for isn't in its site, it looks in Active Directory to find another Client Access server (CAS-2) that is in the same site as the mailbox that it wants to access. When CAS-1 uses CAS-2 as a proxy, CAS-1 uses the InternalURL parameter for CAS-2 to figure out how to connect to it. If your InternalURL is wrong or missing, that server can't be used for proxying.

Back in Exchange Server 2007, only the InternalURL was specified during installation. If your organization had Internet-facing Client Access servers, you had to configure the ExternalURL parameters on the virtual directories after Exchange was installed. However, there is a new screen added to the Exchange Setup process in Exchange Server 2010 that allows you to configure your external URL when the CAS is installed and the appropriate virtual directories are configured for you. This screen is shown in Figure 3.

Figure 3. Configuring the external URL for Client Access servers during Exchange setup

The InternalURL is the server's fully qualified domain name (FQDN), which is also what the default self-signed certificate uses for its subject name. This could potentially be the name that the clients inside your network will use to access the service on your CAS. If you are configuring a CAS only for internal access (either for use by internal clients or for other Client Access servers that proxy requests to it), you should set the ExternalURL parameter to $Null for the virtual directories listed here:

• Outlook Web App

• Exchange Control Panel

• Offline Address Book

• Exchange ActiveSync

• Exchange Web Services

• PowerShell

Table 1 summarizes the recommended InternalURL and ExternalURL configurations. There are some important things that you should note about this information. First, a split-brain DNS architecture is assumed. This means that the namespace used on your internal DNS servers is also the namespace used on your external DNS servers. Technically both zones are authoritative, but the server used will depend on whether the client is coming from inside or outside your network. Second, this information assumes that you are using load-balanced Client Access servers, which we recommend as a standard practice in Exchange 2010. And finally, you should configure the AutoDiscoverServiceInternalUri property to be the FQDN of the load balancer on the CAS and the EWS property called InternalNLBBypassURL should be set to the Client Access server FQDN.

If you don't specify an external URL for your Client Access servers during Exchange setup, the ExternalURL parameter will already be empty. You only need to go back and clear the parameter if you've specified an external URL for your CAS but don't want every web service available externally. For example, you could disable the ExternalURL parameter for the Outlook Web App service, but keep it enabled for the OAB distribution service. You can only clear the ExternalURL parameter on some of the virtual directories using the Exchange Management Console (EMC). For the rest, you will need to use the Exchange Management Shell (EMS). Table 2 lists each EMS cmdlet that you can use to clear the ExternalURL parameter.

The following example demonstrates the usage of the Set-OwaVirtualDirectory cmdlet in the EMS to set the default OWA virtual directory ExternalURL parameter to a null value:

Set-OwaVirtualDirectory "CAS-1\owa (Default Web Site)" -ExternalURL $Null

To demonstrate how the InternalURL and ExternalURL affect proxying, let's take another look at what happens when Nora tries to get to her mail from that Baltimore CAS. Here's what happens when Nora tries to open Outlook Web App: