Chapter 04: Creating and Managing Exchange Clusters (Part3)

Configuring Front-End/Back-End Servers

The mobile workforce is growing as each year goes by. It’s commonplace now for employees to want to make connections to the corporate network using portable computers, 802.11 wireless devices, and even cellular telephones. To that end, Exchange Server 2003 ships with an improved version of Outlook Web Access (OWA) and a new included feature in Outlook Mobile Access (OMA). Although OWA and OMA could serve as a primary means of connecting to your Exchange organization, in most cases, it will be your remote and traveling users who will take advantage of these services. We’ll be examining Outlook Web Access later in Chapter 7, “Configuring Client Access,” but for now it’s enough to understand what its basic purpose is and how it factors into the discussion at hand.

The primary purpose of Outlook Web Access might be something similar to this: to enable remote access to the Exchange organization using industry-standard protocols and applications. In its most basic form, Outlook Web Access is nothing more than an HTTP connection using any recent browser to an Exchange/IIS server that has been configured to pass traffic back to an Exchange server. To increase security, you can (and should) configure an IIS server certificate, thus requiring the use of SSL. Once SSL encryption has been implemented, you can implement Basic authentication of users over the SSL connection. All recent browsers, no matter which operating system, support SSL and thus make ideal candidates for an OWA session.

With this basic description of the process in hand, you should be starting to see inherent security issues that can arise when using OWA. It’s never considered good practice to have secured or unsecured Internet HTTP connections coming directly into your internal protected network. After all, you place your web servers outside at least one firewall, separating them from the rest of your corporate network...don’t you? You will do the same with OWA servers as well, thus configuring Exchange and Outlook Web Access in what we will refer to from here on out as a front-end/back-end (FE/BE) arrangement, as illustrated in Figure 4.5.

Figure 4.5: A basic front-end/back-end arrangement

By looking at the portion of the network shown in Figure 4.5, you can start to determine for which protocols, and thus for which ports, you will need to provide access at the internal and external firewalls. Table 4.1 lists some of the more common ports associated with an Exchange messaging organization that may be using a front-end/back-end configuration.

Table 4.1: The Common Exchange Ports

Port	Function	External Firewall	Internal Firewall
25	SMTP	Open **	Open **
53	DNS	Open	Open
80	HTTP	Open **	Open **
88	Kerberos authentication	Closed	Open
110	POP3	Open **	Open **
119	NNTP	Open **	Open **
143	IMAP4	Open **	Open **
135	RPC port mapping	Closed	Open
389	LDAP to domain controller	Closed	Open
443	HTTP over SSL	Open **	Open **
563	NNTP over SSL	Open **	Open **
993	IMAP4 over SSL	Open **	Open **
995	POP3 over SSL	Open **	Open **
3268	LDAP to global catalog	Closed	Open
1024-65535	RPC service ports (can be manually assigned to a specific port using a Registry modification)	Closed	Open

Note

Items marked by a double asterisk (**) should be opened only if that specific type of traffic needs to be passed through the particular firewall. It is recommended that SSL be used to secure all inbound connections to your organization as much of the time as possible since all common messaging protocols support SSL.

Now that you understand the basic premise of, and reason for, a front-end/back-end server arrangement, let’s look at the tasks you’ll need to perform in order to implement a secure front-end/back-end messaging infrastructure for your clients.

Note

Outlook Web Access, when configured to use SSL, provides a secure and robust messaging experience for users using Internet Explorer 5.01 and later that almost exactly mimics the experience a user would have when connecting to an Exchange Server using Outlook 2003. As an alternative to OWA, you may wish to consider implementing RPC over HTTP for remote users using Outlook 2003, as discussed in Chapter 7.

Configuring Front-End Servers

The basic process to create a front-end/back-end server arrangement is actually pretty simple if you break it down into some basic steps. You first need to determine whether you will be clustering the back-end servers or network load-balancing (recommended) the front-end servers. This decision should be made before you go any further. After this, you only need to install the Exchange servers as previously discussed in Chapter 3 and earlier in this chapter. There is no extra configuration required on the back-end servers above and beyond that of configuring Exchange itself.

Front-end servers require additional configuration but nothing extraordinarily difficult. The first change you will need to make is to configure the front-end servers to act as front-end servers—in other words, let them know that they will be contacting other back-end mailbox and public folder servers instead of actually hosting mailboxes and public folders. This configuration is done from the server Properties dialog box by selecting the This Is A Front-End Server option, as seen in Figure 4.6.

Figure 4.6: Configuring a front-end server

When you close the server Properties dialog box, you will be presented with a warning dialog telling you to restart the Exchange server to complete the configuration change. As well, you will be prompted to install an IIS server certificate so that you can use SSL-secured connections on the server. Once the Exchange server has restarted, you should install the requested IIS server certificate. We will examine server certificates later in Chapter 15, “Securing Exchange Server 2003.”

Front-end servers communicate with back-end servers using TCP port 80—and only TCP port 80. You will not be able to use SSL on port 443 to secure this connection; thus you are highly encouraged to implement an IPSec policy between your front-end servers and back-end servers. You should also IPSec-secure traffic between domain controllers/global catalog servers and your front-end servers.

Note

For more information about configuring and implementing IPSec policies on your network, see Chapter 6, “Deploying Network Services,” from the Windows Server 2003 Deployment Kit at www.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/deployguide/dnsbj_ips_overview.asp.

Securing Front-End Server Services

There are several services that are available by default on an Exchange Server 2003 computer that have no reason to be available on a front-end server. By reducing any unnecessarily running services, you can quickly reduce the attack vector for the server, making your entire organization a little safer. The following services can safely be disabled on your front-end Exchange servers:

• Microsoft Exchange Management

• Microsoft Exchange MTA stacks

• Microsoft Exchange Routing Engine

To disable unnecessary services on your front-end servers, perform the steps discussed in Exercise 4.6.

Note

For even greater security on your front-end servers, and any other server that is located in a screened subnet, see the Windows Server 2003 Security Guide, located at www.microsoft.com/technet/security/prodtech/win2003/w2003hg/sgch00.asp. Chapter 11 of the guide contains information about bastion hosts and includes preconfigured security templates that you may find useful in your organization.

EXERCISE 4.6: Disabling Services on Front-End Servers

---

1. Open the Services console, located in the Administrative Tools folder.

2. Stop the following Exchange-related services:

   • Microsoft Exchange Information Store

   • Microsoft Exchange Management

   • Microsoft Exchange MTA stacks

   • Microsoft Exchange Routing Engine

   • Microsoft Exchange System Attendant

   • World Wide Web Publishing Service

3. Configure the Microsoft Exchange Management, Microsoft Exchange MTA stacks, and Microsoft Exchange Routing Engine services for a startup type of Disabled.

4. Restart the Microsoft Exchange Information Store, Microsoft Exchange System Attendant, and World Wide Web Publishing Service services.

5. Close the Services console.

Summary

Exchange Server 2003 computers can be clustered to provide a highly available solution in environments demanding near 100 percent messaging system uptime. Clustering is not a feature of Exchange Server 2003 itself but instead a feature provided by the operating system: Windows 2000 Server or Windows Server 2003. Exchange, however, is clustering aware, meaning that it can recognize that it is being installed into a cluster and will configure itself appropriately during the installation to support operation in this environment.

Windows Server 2003 provides support for two different clustering methods: Network Load Balancing and the Microsoft Clustering Service. Each of these methods has different purposes and, as you might expect, different hardware requirements.

Network Load Balancing is installed on all participating members as an additional network interface driver that uses a mathematical algorithm to equally distribute incoming requests to all members of the NLB cluster. Incoming client requests are assigned to cluster members based on their current loading level but can be modified through the use of filtering and an affinity for applications that require session state data to be maintained, such as an e-commerce application that uses cookies to place items in a shopping cart for purchase.

The Microsoft Clustering Service is the second clustering method available in Windows Server 2003 and the only one that Exchange Server 2003 supports. MSCS provides for highly available server solutions through a process known as failover. An MSCS cluster consists of two more nodes (members) that are configured such that upon the failure of one node, any of the remaining cluster nodes can transfer the failed node’s resources to itself, thus keeping the resources available for client access. During this time, clients will see little, if any, interruption in service as the resources failover from the nonresponsive node to a remaining functional node.

Clusters using the Microsoft Clustering Service can be created in one of two clustering modes: Active/Active and Active/Passive. When using Exchange Server 2003 on Windows Server 2003 Enterprise Edition or Datacenter Edition, you can create up to eight-node Active/Passive clusters.

When Active/Passive clustering is used, a cluster can contain between two and eight nodes. At least one node must be active and at least one node must be passive. You can have any other combination as well, as long as you meet these minimum requirements. Due to its flexibility and lack of restriction, the Active/Passive clustering mode is the preferred mode of operation for Exchange Server clusters.

When Active/Active clustering is used, each node in the cluster runs one instance of the clustered service. Should a failure of the clustered service occur, that instance is transferred to the other active node. Although you will be able to use both nodes of the cluster in Active/Active mode, you are limited in how many storage groups and Exchange mailboxes each node can host because a single Exchange server can hold only four production storage groups. In addition to this restriction, the nodes in an Active/Active cluster can have only 1,900 active mailboxes each, which is several thousand less than an Exchange server might typically be able to hold.

You should deploy your Exchange servers in a front-end/back-end configuration for increased security and greater flexibility. The front-end servers, which are located in your screened subnet, provide only a secure connection point for those users located on the Internet to connect to your Exchange organization. SSL is used to secure the traffic in this connection. Front-end servers then pass information back and forth between back-end servers and clients. Therefore, clients never directly connect to a back-end server, which is located in your private, protected network. IPSec can be used to secure the connections between the front-end servers and back-end servers, domain controllers, and global catalog servers for further security. Front-end servers can also be set up in a Network Load Balancing cluster for improved availability.