Designing an Exchange Front-endBack-end OWA Architecture

Designing an Exchange Front-end/Back-end OWA Architecture

The ability to configure front-end servers is a new concept introduced in Exchange 2000 and improved upon in Exchange Server 2003. Exchange 5.5 allowed an ASP-based front-end server for Outlook Web Access by enabling a dedicated IIS server to handle OWA client traffic, but Exchange 2000/2003 enables an increased degree of flexibility by offloading all protocols and enabling load balancing of those servers.

Front-end servers contain no mailboxes, and proxy HTTP, POP3, and IMAP traffic to a back-end server. They cannot, however, handle MAPI request in the same way, because MAPI clients must communicate directly with the server containing the client's mailbox. The term back-end server refers to any Exchange 2000/2003 server that contains the mailbox store and is configured to communicate with a front-end server for IMAP, HTTP, or POP3. Back-end servers could handle all the tasks that the front-end servers handle, but separating front-end/back-end responsibilities provides the following benefits:

• Isolates the Servers Containing the Mailbox Store This enables the servers with mailboxes to remain in a secure network, and the front-end servers can be placed in the DMZ where an attack is more likely.

• Offloads Processing Overhead for Encryption/Decryption Processes SSL-based encryption and decryption processes, which are used to secure HTTP, POP3, and IMAP, add 15% to 40% processor overhead to the Exchange Server and can be delegated to the front-end server.

• Enables Multiple Servers to Have the Same Alias in DNS Using a DNS round-robin between Exchange servers with mailbox stores forces users to authenticate twice if the first server they are directed to does not contain their mailbox. This will not occur with front-end servers configured in a round- robin as long as all front-end servers can communicate directly with all mailbox store servers.

• Enables Automatic Referrals to Public Folder Content for IMAP Clients Many IMAP clients do not handle referrals to other servers. When an IMAP client needs folder content that might be available on another server, a front-end server will handle the referral and provide the public folder content for the IMAP client.

Front-end/Back-end Servers

When a client connects to a front-end server for HTTP access, the front-end server queries Active Directory to find the correct back-end server that contains the user 's mailbox. The front-end server then sends the request to the back-end server, with the HTTP host header unmodified.

For the back-end server to respond to the front-end server's request, an HTTP virtual server must exist on the back-end server that is configured to communicate with the front-end server. Both the front-end server and back-end server must have identical HTTP virtual servers for this communication to take place. This is an important consideration because it effectively means that the back-end HTTP virtual server or servers must be enabled for front-end OWA to function properly. The back-end server treats the front-end server the same as it would a client who connected directly to the back-end server. When the back-end server responds to the client request, the communication travels through the front-end server unchanged.

NOTE

Each Exchange Server 2003 system can contain multiple HTTP virtual servers. This is useful in situations where an OWA server needs to respond to requests from OWA clients from multiple domains. For example, if a single OWA server will respond to owa.companyabc.com , owa.company123.org , and owa.organizationy.com , virtual servers need to be set up for each domain on both the front-end and back-end server, because the host header information does not change when proxying requests.

The following are a few facts to note regarding the communication between the front-end and back-end server:

• Front-end and back-end servers communicate only over port 80 . Trying to use any other port on the virtual server, such as 8080, will not work.

• SSL cannot be used between front-end and back-end servers to secure communication . Use IPSec to secure traffic between front-end/back-end servers when it must traverse unsecured networks.

• Front-end servers support only HTTP 1.1 basic authentication . If users will be connecting to the server over the Internet, SSL should be enabled on the front-end server to secure the session and the user's credentials.

• When authenticating to the front-end server, users need to enter the domain name . User credentials need to be entered in the format domain/username.

Planning for Front-end OWA Servers

The general recommendation from Microsoft is to plan for one front-end server for no more than four back-end servers. Front-end servers require fast processors to handle tasks such as encryption through SSL or IPSec, and they should also be configured with sufficient memory. Large disks are not required in the front-end servers because they have unpopulated mail store databases or no databases at all. The level of fault tolerance in the front-end server is really up to the organization. If features such as network load balancing are enabled, it might not be worth spending the extra dollars for RAID controllers, redundant fans, and network adapters. If NLB is not used, organizations should consider at least hardware RAID 1 disk configuration.

Securing Communications on Front-end Servers

If the front-end server will be used for Internet clients, the communication between the client and the server should be secured using SSL.

NOTE

For steps on configuring a front-end server for SSL see the section later in this chapter, "Using SSL to Secure Access to the Front-end Server."

If secure communication is needed between the front-end and back-end servers, IPSec can be implemented. The back-end server should be configured for Client (respond only) so that IPSec is not required for MAPI client access. On the front-end server, only HTTP traffic initiated by the front-end server on Port 80 should be configured for IPSec. IPSec firewalls will have to be opened for IP identifiers 50 and 51.

Understanding Authentication in Front-end/Back-end Servers

When connecting to the front-end server, the user can be authenticated in a number of places. Depending on the security policy for the organization, users can be authenticated at the back-end server or both the front-end and the back-end servers.

If the front-end server is enabled for authentication, the users can connect to the front-end server using an implicit logon or an explicit logon. This implicit logon is in the format of http://server/exchange and the explicit logon is in the form of http://server/exchange/username . When authentication is disabled on the front-end server, users must use the explicit logon and are authenticated by the back-end server only.

Users will always be authenticated on the back-end server regardless of the front-end configuration; however, if the front-end server is enabled for authentication, the authentication credentials are passed from the front-end server to the back-end server automatically, so users are prompted only once to authenticate. Behind the scenes, however, the servers process the authentication twice.

Not using authentication on the front-end server has a few disadvantages besides not being able to use implicit logons . When authentication is enabled, administrators can configure a simplified URL for OWA access, so users do not have to attach /exchange to the http:// servername . To configure a simplified URL, open Internet Services Manager. Configure the Default Web Site Home Directory on the front-end server to A redirection to a URL and enter /exchange in the Redirect to box, as shown in Figure 10.2. Remember to mark the check box for A directory below URL entered; otherwise , the redirection will not work.

Figure 10.2. Configuring a simplified URL.

With authentication disabled on the front-end server, public folder requests cannot be load-balanced . When front-end servers authenticate the user, they know which public folder the user is configured for and make sure the user is connected to the correct public folder server. The front-end server can also query Active Directory and direct users to the appropriate public folder server for public folder applications. If a user requests content that is not available on the user's home public folder server, the front-end servers keep a cache of which public folder replicas exist on each public folder servers to get users to the content more quickly on subsequent requests.

To disable authentication on the front-end server, use Internet Services Manager and access the properties of each virtual directory in the HTTP virtual server on the front-end server. Use the Authentication button on the Access tab and uncheck Integrated Windows authentication and Basic authentication; then check Enable anonymous access, as shown in Figure 10.3. After this, enter the account to use for anonymous access.

Figure 10.3. Disabling front-end server authentication.

NOTE

For security reasons, it is not generally recommended to disable authentication on the front-end server, because it leaves the back-end servers open to denial-of-service attacks, negating some of the protections that the front-end servers provide.

Configuring a Firewall for Front-end Servers

To use a front-end/back-end server configuration with firewalls, the front-end server must be able to initiate a connection to the back-end server. If the front-end server is behind a firewall, the organization's security policy must permit the front-end server to initiate the connection to the back-end server or the organization will not be able to use front-end/back-end servers.

For client access to the front-end server, the following ports must be open from the Internet to the front-end server or servers. If one or more of these protocols will not be supported, they can be disabled:

• 443/TCP HTTPS HTTP secured with SSL.

• 993/TCP IMAPS IMAP secured with SSL.

• 995/TCP POP3S POP3 secured with SSL.

• 25/TCP SMTP Required for relaying from POP3 and IMAP clients or receiving Internet mail from the outside. This is not required if SMTP mail is relayed from another location or not allowed.

NOTE

Although it is not normally recommended to allow non-encrypted traffic over the "normal" ports for HTTP, IMAP4, and POP3 (80, 143, and 110), it can be allowed, depending on the security requirements of the organization. In addition, if port 80 is open, clients need to be educated to access the server over an https:\\ connection. If this is not feasible , port 80 has to be opened, and a special Web page can be placed that automatically redirects clients to use the SSL port.

For the front-end server to communicate with the back-end server, the following ports must be open between the front-end server(s) and the internal network:

• 80/TCP HTTP

• 143/TCP IMAP

• 110/TCP POP3

• 25/TCP SMTP

• 389/TCP LDAP Access to Active Directory

• 3268/TCP Access to the Global Catalog

• 88/TCP Kerberos Authentication

• 88/UDP Kerberos Authentication

It's also recommended to open Port 53 for TCP and UDP to enable the front-end server to query DNS for the global catalog and domain controller records. If the DNS ports are not open, a host file can be used on the server. The host file should list all global catalog and domain controller servers that the front-end server needs to contact.

Exchange Server 2003 front-end servers have reduced their reliance on requiring RPC between the front-end servers and the AD domain controllers, but unfortunately have not completely divorced themselves from this role. Specifically, front-end servers require RPC for client authentication and to do queries to locate AD domain controllers and global catalog servers.

To support client authentication on the front-end server, the following additional ports should be opened:

• 135/TCP RPC Port Endpoint Mapper

• 1024+/TCP RPC Service Ports

• 445/TCP Netlogon

If it is not possible to open dynamic RPC ports between front-end servers and the AD domain controllers, it might be possible to force AD to communicate over specific ports through a Registry change on all domain controllers. Because this requires production domain controller changes that differ from general best practice, it is not normally recommended.

Disabling Unnecessary Services on the Front-end Server

Front-end servers require only a few services to operate . Listed are the services that are required by each protocol on the front-end server:

• HTTP World Wide Web Publishing Service and Exchange System Attendant

• POP3 Exchange POP3, Exchange System Attendant, and Exchange Information Store

• IMAP Exchange IMAP, Exchange System Attendant, and Exchange Information Store

NOTE

All Exchange services other than the HTTP, POP3, and IMAP services should be left disabled in the Services snap-in on the front-end servers. This ensures that the front-end server processes only the tasks necessary to be dedicated to service.

By default, in POP3 and IMAP configurations, the front-end server requires a storage group on the server even though it might not contain any databases. The storage group can be removed if the dependencies on the Exchange information store are removed in the Registry. To remove the POP3 and IMAP front-end servers' dependency on the Exchange Information Store, remove the MSExchangeIS entry from the DependOnService Registry entries in the following Registry keys:

 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IMAP4SVC HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\POP3SVC 

When a firewall separates the front-end and back-end servers and the RPC ports are not open, the POP3 and IMAP dependency on the Exchange Information Store must be removed.

For HTTP, POP3, and IMAP configurations, all public folder store databases should be deleted from the server. Mail store databases can be left on the server as long as they do not contain any mailboxes. Leaving the mail store databases on the server enables the Internet Service Manager to be run against the server, so items such as the SSL configuration can be modified.

Front-end servers that receive mail from the Internet need to retain at least one private information store so non-delivery receipts (NDRs) can be sent to Internet users. If one store is not mounted, the message conversion cannot take place and the NDR messages become stuck in the local delivery queue. An information store database is also required if there are Exchange 5.5 servers in the same routing group to enable the MTA to transfer mail over RPC.

Reducing Server Configuration

As the number of front-end servers grows, the overhead of configuring each back-end server to communicate with the front-end servers grows too. Remember that each back-end server must have a corresponding HTTP virtual server for each front-end server. Using a single HTTP virtual server on the back-end server configured for all front-end servers is possible and can help reduce the HTTP virtual server configuration overhead with a large number of front-end servers. This technique can be used as long as the front-end server configurations are identical.

Two methods of configuring front-end/back-end servers exist. Organizations have the option of building new HTTP virtual servers on the front-end and back-end servers, or they can choose to use the default HTTP virtual servers that are created during the Exchange Server 2003 installation. The easiest method is to use the default virtual server configuration. Organizations should not consider creating new virtual servers and building a custom configuration unless they have been successful in the lab with front-end/back-end servers in the default virtual server configuration.

Configuring Network Load Balancing for Front-end Servers

A DNS-based round-robin can be used to load-balance between front-end servers by creating multiple A records for each front-end server with the same hostname ”for instance, mail.company.com . This solution provides primitive load balancing and works well while all servers are online. The disadvantage to this solution is that the DNS will still return the IP address of a failed server in the round-robin.

A better solution for load balancing is to use the Network Load Balancing (NLB) feature of Windows Server 2003. NLB uses a virtual IP address for all connections to the front-end servers. NLB will not attempt to connect with an offline server. SSL can also be used on front-end servers in the NLB cluster to secure client communication. When using SSL and NLB, use the default Client Affinity setting of Single to preserve the client session state between a client and a specific node in the NLB cluster.