Configuring Front-EndBack-End Servers


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.

 



MCSA[s]MCSE
MCSA[s]MCSE
ISBN: 735621527
EAN: N/A
Year: 2004
Pages: 160

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net