| 0 comments ]

Configuring Front-End/Back-End Servers

Add a note here 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.

Add a note hereThe 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.

Add a note hereWith 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.

Click to collapse
Add a note hereFigure 4.5: A basic front-end/back-end arrangement

Add a note hereBy 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.

Add a note here Table 4.1: The Common Exchange Ports

Add a note herePort

Add a note hereFunction

Add a note hereExternal Firewall

Add a note hereInternal Firewall

Add a note here25

Add a note hereSMTP

Add a note hereOpen **

Add a note hereOpen **

Add a note here53

Add a note hereDNS

Add a note hereOpen

Add a note hereOpen

Add a note here80

Add a note hereHTTP

Add a note hereOpen **

Add a note hereOpen **

Add a note here88

Add a note hereKerberos authentication

Add a note hereClosed

Add a note hereOpen

Add a note here110

Add a note herePOP3

Add a note hereOpen **

Add a note hereOpen **

Add a note here119

Add a note hereNNTP

Add a note hereOpen **

Add a note hereOpen **

Add a note here143

Add a note hereIMAP4

Add a note hereOpen **

Add a note hereOpen **

Add a note here135

Add a note hereRPC port mapping

Add a note hereClosed

Add a note hereOpen

Add a note here389

Add a note hereLDAP to domain controller

Add a note hereClosed

Add a note hereOpen

Add a note here443

Add a note hereHTTP over SSL

Add a note hereOpen **

Add a note hereOpen **

Add a note here563

Add a note hereNNTP over SSL

Add a note hereOpen **

Add a note hereOpen **

Add a note here993

Add a note hereIMAP4 over SSL

Add a note hereOpen **

Add a note hereOpen **

Add a note here995

Add a note herePOP3 over SSL

Add a note hereOpen **

Add a note hereOpen **

Add a note here3268

Add a note hereLDAP to global catalog

Add a note hereClosed

Add a note hereOpen

Add a note here1024-65535

Add a note hereRPC service ports (can be manually assigned to a specific port using a Registry modification)

Add a note hereClosed

Add a note hereOpen


Note

Add a note hereItems 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.

Add a note hereNow 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

Add a note hereOutlook 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.

Add a note here Configuring Front-End Servers

Add a note hereThe 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.

Add a note hereFront-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.

Click to collapse
Add a note hereFigure 4.6: Configuring a front-end server

Add a note hereWhen 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.”

Add a note hereFront-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

Add a note hereFor 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

Add a note hereThere 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:

  • Add a note hereMicrosoft Exchange Management

  • Add a note hereMicrosoft Exchange MTA stacks

  • Add a note hereMicrosoft Exchange Routing Engine

Add a note hereTo disable unnecessary services on your front-end servers, perform the steps discussed in Exercise 4.6.


Note

Add a note hereFor 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.

Add a note here EXERCISE 4.6: Disabling Services on Front-End Servers

  1. Add a note hereOpen the Services console, located in the Administrative Tools folder.

  2. Add a note hereStop the following Exchange-related services:

    • Add a note hereMicrosoft Exchange Information Store

    • Add a note hereMicrosoft Exchange Management

    • Add a note hereMicrosoft Exchange MTA stacks

    • Add a note hereMicrosoft Exchange Routing Engine

    • Add a note hereMicrosoft Exchange System Attendant

    • Add a note hereWorld Wide Web Publishing Service

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

  4. Add a note hereRestart the Microsoft Exchange Information Store, Microsoft Exchange System Attendant, and World Wide Web Publishing Service services.

  5. Add a note hereClose the Services console.


Summary

Add a note here 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.

Add a note hereWindows 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.

Add a note hereNetwork 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.

Add a note hereThe 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.

Add a note hereClusters 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.

Add a note hereWhen 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.

Add a note hereWhen 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.

Add a note hereYou 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.

0 comments

Post a Comment