Many enterprise Exchange 2000 Server users and an increasing number of users in small organizations use Outlook 2002 (or earlier versions) as their email client inside the corporate environment. When these users need access to their mailboxes from outside the corporate environment, they can employ one of several approaches, including a dial-up connection that uses a Windows 2000 Routing and Remote Access or Windows NT 4.0 RAS VPN. More commonly, though, users turn to Outlook Web Access (OWA) to access their Exchange mailboxes.
To access Exchange mailboxes from a Web browser, users need to establish HTTP connections from the Web browser to an Exchange 2000 front-end server or an Exchange 2000 back-end server on the corporate network. Although many OWA users connect directly to back-end servers, other users connect to front-end servers. Using front-end servers lets users enter a simple URL in the browser (e.g., http://mail.acme.com), whereas connecting to a back-end server requires that they enter the name of the Exchange server on which their mailboxes reside. The Exchange 2000 front-end server then proxies the HTTP con- nection to the appropriate Exchange 2000 back-end server. This proxy approach uses one of several techniques that have varying degrees of complexity, cost, and security. The basic architecture is simple: Protect the Active Directory (AD) servers and back-end Exchange servers by safely placing them on the most protected part of the network, and expose only the front-end servers (which effectively perform only a proxy function) in the demilitarized zone (DMZ). Although the proxy approach is relatively conventional, it's far from simple because of the configuration's complexity and can be insecure because of the number of holes it makes in internal-facing firewalls.
Using Exchange 2000 Front-End Servers in the DMZ
You don't want to open up your corporate external-facing firewall to let Web browser clients directly access front-end and back-end servers on an internal network. (This statement holds true for all forms of clients, including IMAP and POP clients.) Opening up your external firewall is unwise because it lets any computer on the Internet connect over HTTP or HTTP Secure (HTTPS) directly to front-end servers on your network. Intruders can then easily mount malicious attacks because no barrier exists between your front-end servers and the rest of the corporate network.
To mitigate this security concern, one common practice involves placing front-end servers in the DMZ—behind the external firewall—and back-end servers on the internal part of the network—behind a second, internal firewall. This approach appears reasonable because Web browsers connect to front-end servers through the limited set of open ports on the external-facing firewall and connections must pass from the front-end servers to the back-end servers through a second firewall, as Figure 1 shows. But although this architecture appears to be secure, holes exist in both the external-facing firewall and—more significantly—the internal-facing firewall.
Table 1 defines the ports that are required for Internet traffic from the external-facing firewall to the DMZ. You should enable basic HTTP and HTTPS because users can use both protocols to access Exchange mailboxes. I don't recommend using basic HTTP because it passes authentication credentials over the Internet unencrypted; instead, use HTTPS, which provides encryption. HTTPS uses Secure Sockets Layer (SSL), which requires a certificate on the server for the authentication process with the client. You can obtain certificates from the Microsoft Certificate Authority (CA) service or from an Internet CA. HTTPS is the preferred mechanism for access and is mandatory if your users want to change passwords from the OWA client. Table 2 defines the required ports for traffic from the DMZ through the internal-facing firewall to the internal network. You can see that the internal firewall opens quite a few ports.
Exchange 2000 SP2, DSAccess, and Firewalls
Versions of Exchange 2000 earlier than Service Pack 2 (SP2) use remote procedure calls (RPCs) to facilitate connections from the DSAccess component on the front-end server to domain controllers (DCs) and Global Catalog (GC) servers on the internal network. SP2 significantly improves the process of controlling port access for DSAccess traffic from front-end servers in the DMZ to internal DCs and GCs. SP2 uses Lightweight Directory Access Protocol (LDAP) for DSAccess-to-DC/GC communication in front-end/back-end environments, but DSAccess attempts to use the Netlogon service to communicate with each DC and GC that it discovers. You might want to block RPC traffic across the internal-facing firewall (see the "Should You Allow RPCs Across Your DMZ?" section for a discussion about whether you should allow RPC traffic), but I don't recommend doing so. If you do, DSAccess simply determines that the RPC traffic is blocked but that DCs and GCs are still available.
To improve performance by lessening CPU usage, you can disable Netlogon checking by setting the HKEY_LOCAL_MACHINE\SYSTEMCurrentControlSet\Services\MS ExchangeDSAccess registry subkey, of type REG_DWORD, to a value of 1. In DMZ firewall environments, the internal-facing firewall often blocks Internet Control Message Protocol (ICMP) packets to prevent system discovery and Denial of Service (DoS) attacks. The modified DSAccess that ships with SP2 uses ICMP pings to validate the availability of DCs and GCs. Blocking ICMP traffic therefore causes DSAccess to assume that DCs and GCs are unavailable and to use LDAP to force new topology discoveries. Because this process can negatively impact performance, I recommend that you disable DSAccess ICMP pings to the DCs and GCs by setting the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess registry subkey, of type REG_DWORD, to a value of 0.
Should You Allow RPCs Across Your DMZ?
Figure 2 shows an implementation scenario that lets RPC traffic travel from servers in the DMZ across the internal-facing firewall to the intranet. I just demonstrated that DSAccess in Exchange 2000 SP2 doesn't require RPC access to DCs and GCs on the intranet, so why would you want to allow RPC traffic? The short answer is authentication. When an OWA user connects to a front-end server, the front-end server can authenticate the user immediately or forward the authentication request anonymously to the back-end server for authentication on that server only.
If you want to prevent all RPC traffic, configure only the back-end server to perform OWA authentication. This so-called pass-through authentication is desirable because it doesn't require trans-firewall RPCs, but it's undesirable because it complicates the URL addresses that OWA users must specify—they must specify their usernames in the URL (e.g., http://mail .acme.com/exchange/fiorina) so that the front-end server can look them up in AD and forward the request to the appropriate back-end server. If a front-end server performs the authentication, however, the URL can be much more generic (i.e., http://mail .acme.com). This generic URL is easier for offsite users to remember and use. But pass-through authentication is undesirable for an additional reason: It explicitly directs all anonymous authentication requests to back-end servers in the intranet, making these back-end servers, which might also service conventional Messaging API (MAPI) logons, susceptible to DoS attacks.
I recommend using a dual-authentication process in which both front-end and back-end servers use basic authentication to authenticate OWA user connections. However, this process requires that the front-end server have RPC connectivity to DCs and GCs in the intranet.
Generalized Internal-Facing Firewall Requirements
The port definitions in Table 1 and Table 2 provide a general picture of requirements for facilitating OWA browser access to front-end servers in the DMZ and back-end servers in the intranet. Particular environments might require different port definitions. For example, you might use multiple front-end servers, back-end servers, DCs, GCs, and load-balancing switches. The tables don't define source ports and traffic direction, so you'll need to customize your specific environment as appropriate. Be as restrictive as you can when you start testing, then gradually open up ports and directions as required until you observe typical behavior. As always, perform your testing in a strict lab environment and carefully document your results before you transfer the process to your production environment.
As one of the required ports and protocols, you'll need to configure on some DCs and GCs a fixed port over which AD authentications are serviced. In Figure 2 and Table 2, I've noted that you should set port 1127 on DCs and GCs for the logon service. You can do so by setting the HKEY_ LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters registry subkey, of type REG_ DWORD, to the value of 1127.
You might want to consider port and protocol requirements in addition to those listed in Table 1 and Table 2. For example, you might want to open up ports for various management and monitoring tools. How will you manage the front-end servers that reside in the DMZ? Even if you plan to use the basic Microsoft Management Console (MMC) Exchange System Manager snap-in, you'll need to open up the internal-facing firewall to allow RPC connections to the front-end servers. (In general, however, outbound connections from the intranet to the DMZ are less of a problem because you can trust the source of the connections.) You can employ an alternative method, such as using Win2K Server Terminal Services RDP over port 3389 to access and manage front-end servers. You can also use a combination of Windows Management Instrumentation (WMI) or Collaboration Data Objects for Exchange Management (CDOEXM) scripts run through a browser to manage the servers, although you might want to consider the impact of enabling Terminal Services on vulnerable systems in the DMZ. Using VPN connections to manage those systems is a slightly more secure approach.
Although you can strictly identify the source computer in the DMZ—the front-end server in this case—and allow only traffic from it to pass through the internal-facing firewall, an attacker could compromise the source computer and turn it into the platform for a malicious attack on your internal network. An in-depth analysis of the port and protocol requirements reveals that this front-end/ back-end approach, although relatively straightforward to implement, doesn't have a high degree of associated security.
Many companies have implemented this approach to give offsite users OWA access. In a future article, I'll describe alternative approaches that use SSL proxies and are inherently more secure: a software approach that uses Microsoft Internet Security and Acceleration (ISA) Server 2000 and a hardware approach that uses SSL Proxy network appliances from vendors such as FSNetworks, Cisco Systems, and Radware.
