Two of the biggest complaints about Exchange Server 5.5's Outlook Web Access (OWA) were that it wasn't very secure or scalable. Significant security problems still exist in OWA in Exchange 2000 Server (OWA 2000) if you configure it improperly. However, OWA 2000 adequately addresses the scalability problems through more efficient communication between the Microsoft Internet Information Services (IIS) 5.0 server and Exchange 2000 servers and through the use of front-end and back-end servers. Let's look at the reasons for implementing front-end and back-end servers, how to create and properly configure them, and how to secure your new OWA setup by adding a firewall, protecting and changing passwords, and protecting against possible attacks. In addition, on the Exchange & Outlook Administrator Web site (http://www .exchangeadmin.com), you'll find the Web-exclusive sidebar "Redirecting Users to Secure Pages," InstantDoc ID 23175, which describes how you can help users adjust to secure Web pages in the OWA 2000 system.
Reasons for Using Front-End and Back-End Servers
Exchange 2000's ability to support front-end servers for Internet protocol clients such as HTTP, POP3, IMAP4, and Network News Transfer Protocol (NNTP) is exciting news. (Messaging API—MAPI—clients, such as Outlook 2000 and Outlook 9x, don't use front-end servers.) For large organizations, this support promises to improve the scalability and performance of Exchange 2000 in environments with thousands of Internet-protocol clients. Although organizations with only a few clients and one or two servers don't need a front-end server for scalability, they can implement a front-end server for other reasons, including
- off-loading the overhead of authentication and encryption (Secure Sockets Layer—SSL) from the back-end servers
- providing IMAP4 clients access to all public folders, not just the public folders that have a replica on the user's home server
- having a buffer in the perimeter network or demilitarized zone (DMZ), between the firewall and the Internet
- providing one namespace for all users to connect to their mail, regardless of the name or location of the back-end server
You can configure only Exchange 2000 Enterprise Server as a front-end server. When you use an Internet-protocol client, the front-end server acts as a connection point to back-end servers. All communication travels through the front-end servers to the back-end Exchange 2000 servers, on which the mailboxes and public folders reside; the client communicates only with the front-end server. A DNS entry can point to one front-end server, or you can configure the DNS entry to cycle in a round-robin style through several front-end servers. If you choose to have several front-end servers, you should implement a load-balancing solution such as Microsoft's Windows NT Load Balancing Service (WLBS).
Creating and Configuring a Front-End Server
All Exchange 2000 servers are back-end servers by default. To create a front-end server, install Enterprise Server. Use the Microsoft Management Console (MMC) Exchange System Manager (ESM) console to locate that server in the administrative group's Servers container and display its properties, as Figure 1 shows. Select the This is a front-end server check box, click OK, and reboot.
If you previously installed Enterprise Server and that server contains mailboxes and public folders replicas, you perform the same steps I just described to convert that server to a front-end server. However, you need to move the mailboxes and public folders to another server before the conversion. After you reboot the front-end server, any mailboxes or public folders on that server will no longer be accessible. If you forget to move a mailbox or public folder, you can reverse the process and the mailboxes and public folders will be available again.
To optimize the front-end server, I recommend that you dismount the mailbox store and public folder store on the front-end server. Although you could delete these stores, deleting them prevents you from using the IIS administration tools to make changes. You can disable the other Exchange 2000related services, such as the Microsoft Search Service, the Routing Engine service, the Message Transfer Agent (MTA) service, and the Exchange Event Service. However, if you want the front-end server to provide SMTP mail services, you must leave the Routing Engine service enabled and you must mount the mailbox store so that the SMTP mailbox is available.
Finally, make sure that the front-end server's virtual directories (e.g., HTTP, POP3, IMAP4, NNTP) and virtual servers (e.g., HTTP) are the same as those on the back-end server. If you haven't created any additional HTTP virtual directories or Internet protocol virtual servers, you won't need to make any changes.
Be aware that when you shut down or reboot a back-end server, the front-end server marks that server as unavailable for 10 minutes. If the front-end server receives a request for a public folder on the unavailable back-end server, the front-end server attempts to redirect the request to another back-end server. If the request is for a mailbox, the front-end server can't redirect the request, so it waits 10 minutes, then tries to connect to the back-end server. If the back-end server comes back online, a few minutes might pass before the front-end server connects to the back-end server.
Adding a Firewall
A firewall is a necessity for networks that connect to the Internet or any other outside network. Figure 2, page 8, shows a common firewall configuration. As Figure 2 shows, you place the front-end server in the DMZ. The internal network isn't accessible from the Internet, but certain applications on servers in the DMZ are accessible from the Internet. The servers in the DMZ can access applications on the internal network, subject to the constraints the firewall places on them.
To place a front-end server in the DMZ, you need to open several TCP ports between the Internet and the front-end server. Table 1 lists the ports you must open. Because you're opening basic protocol ports (e.g., port 80), I strongly recommend that you require SSL for all HTTP, POP3, and IMAP4 communications from the Internet.
You also need to open several TCP and UDP ports between the front-end server in the DMZ and the back-end servers on the internal network. Table 2 lists the ports that you must open. If you choose to restrict the traffic to only specified IP addresses, make sure that the IP addresses in the DMZ can communicate with all back-end servers that contain the mailboxes that the Internet users will be accessing.
All HTTP communication between the front-end and back-end servers takes place over TCP port 80, a clear-text port, regardless of whether the client uses SSL to talk with the front-end server. Thus, all HTTP communication between the front-end and back-end servers is in clear text, which means that someone inside the system can monitor the network and read passwords and mail messages between the front-end and back-end servers. If you require secure communications between the front-end and back-end servers, you should implement IP Security (IPSec).
Table 2 doesn't include SSL ports for HTTP, POP3, and IMAP4 (i.e., TCP ports 443, 993, and 995) or NetBIOS ports (i.e., TCP and UDP ports 137, 138, and 139). You don't need to open the SSL ports because the front-end server doesn't use SSL to communicate with the back-end servers. Because you don't open the NetBIOS ports, you can't map drives between the front-end and back-end servers. In addition, if you're using Exchange 2000 Service Pack 2 (SP2), the remote procedure call (RPC) ports between the front-end and the back-end servers aren't necessary.
If you plan to use Transport Layer Security (TLS)/SSL for servers that operate in a cluster, you need to enable more than just the SSL ports because the cluster service polls the known service ports (e.g., HTTP, POP3). If the ports don't respond, failover to another node in the cluster can occur. For more information about implementing front-end and back-end servers, see the Microsoft article "Exchange 2000 Front-End and Back-End Topology" (http://www.microsoft .com/exchange/ techinfo/deployment/2000/e2kfront back.asp).
Protecting Passwords and Mail Messages
If you use OWA to connect your clients to a back-end server, you can enable Integrated Windows authentication. This authentication method prevents passwords from being transmitted over the network. However, Integrated Windows authentication requires that your clients use Microsoft Internet Explorer (IE) 4.0 or later. If your clients use Netscape Navigator or another browser, you must enable Basic authentication.
Front-end servers support only Basic authentication. You should use ESM to configure each virtual directory's Basic authentication setting. Don't use the MMC Internet Information Services snap-in because Exchange 2000's Directory Service to Metabase (DS2MB) process will overwrite the metabase settings during the metabase update process. To configure Basic authentication, in ESM, open the HTTP virtual directory's Properties page. On the Access tab, click Authentication. In the Authentication Methods dialog box that appears, select the Basic authentication check box and enter the default domain, as Figure 3 shows.
Basic authentication sends the username and password over the network in an obfuscated but easily decoded format that's essentially the same as clear text. Transmitting an easily decoded password over the Internet is a serious security risk. Many organizations consider HTML-formatted mail messages traveling over the Internet equally risky. To avoid these risks, you can enable SSL on the IIS servers that support OWA. Specifically, you enable SSL on the default Web site or the Web site that's hosting the Exchange virtual directories. In the Internet Information Services snap-in, open the target Web site's Properties dialog box. On the Document Security tab, click Server Certificate and follow the Web Server Certificate Wizard's prompts to create a certificate request. Send the certificate to a trusted Certificate Authority (CA), such as Thawte or Baltimore Technologies. When you request a certificate, you need to specify the common name. This name is the Fully Qualified Domain Name (FQDN) of the server on which you're installing the certificate (i.e., owa.somorita.com).
An alternative is to install the Win2K Certificate Server and create custom certificates. The disadvantage of creating custom certificates is that your clients' browsers might not trust your signing authority. When clients connect to Web servers that have custom certificates the clients' browsers display a Security Alert dialog box that states The security certificate was issued by a company you have chosen not to trust. To avoid this dialog box, you can install the server's certificate in the browsers' local certificate store.
When requesting a certificate or creating a custom certificate, you must choose the public and private key lengths (e.g., 512 bits, 1024 bits). You also must choose whether you want to require 128-bit encryption between the client's browser and the server. Longer key lengths are more secure than shorter key lengths, but the longer key lengths require more processing overhead on OWA 2000 servers. If you require 128-bit encryption and use 1024-bit keys, you might reduce the total number of users that an OWA 2000 server can support by as much as 50 percent. In addition, if you require 128-bit encryption on the server side, all the clients must support 128-bit browsers.
You can use the Internet Information Services snap-in to configure IIS to require 128-bit encryption. In the Internet Information Services snap-in, display the Properties dialog box for the Web site for which you want to use 128-bit encryption and select the Directory Security tab. Click Edit in the Secure Communications section to obtain the Secure Communications dialog box, which Figure 4, page 10, shows. Select the Require secure channel (SSL) and the Require 128-bit encryption check boxes.
Changing Passwords Through OWA
To help protect the OWA 2000 system, users should periodically change their passwords. You can let users change their own passwords with the Change password option in OWA 2000's Option dialog box. For this option to work, the IIS server must support SSL and you must configure IIS to support password changes.
To configure IIS, you must use the Internet Information Services snap-in to create a virtual directory called IISADMPWD on the IIS server. This virtual directory should point to the \winnt\system32\inetsrv\iisadmpwd directory. When you run the new virtual directory wizard to create IISADM PWD, confirm that the Read, Run Script, and Execute Access check boxes are selected for this virtual directory. In the IISADMPWD virtual directory's Directory Security Properties dialog box, confirm that the Anonymous access authentication method is enabled; Anonymous access must be enabled for the user to access the password change screen properly. For more information about enabling password changes through IIS, see the Microsoft article "How to Enable Password Change Functionality for Microsoft Exchange Server Outlook Web Access" (http://support.microsoft.com/support/ kb/articles/q268/4/19.asp).
After you complete these configurations, users can click Change password in the Options dialog box and change their password. Users must enter the domain name, username, original password, and new password.
If you're running Exchange 2000 in a clustered environment, you need to perform a few additional steps to enable the Change password option. For information about enabling password changes on clusters, see the Microsoft article "XWEB: How to Enable the Change Password Option in Exchange 2000 OWA Clustering" (http://support.microsoft.com/support/ kb/articles/q277/9/08.asp).
After users change their password, they can log on through OWA with either the new password or the old password for up to 15 minutes, but they must immediately use the new password when logging on through MAPI. This difference is by design: Microsoft incorporated the 15-minute interval in OWA for performance reasons. You can change the default interval by modifying a registry subkey. On the IIS server that supports OWA, locate the HKEY_ LOCAL_MACHINE\SYSTEM\Current ControlSet\Services\InetInfo\Param eters subkey and add a new REG_ DWORD value named UserTokenTTL. When prompted, enter the number of seconds you want the interval to be. The number you enter needs to be a hexadecimal value, unless you select the Decimal option. The change will affect users that log on in the future but not those currently logged on.
Because changing this interval significantly affects performance, I recommend leaving the default. For more information about changing the subkey and its implications, see the Microsoft articles "XWEB: Old Password Still Works After You Change It Through Outlook Web Access" (http:// support.microsoft.com/support/kb/articles/ q267/5/68.asp) and "Changing the Default Interval for User Tokens in IIS" (http://support.microsoft.com/ support/ kb/articles/q152/5/26.asp).
Protecting Against Attacks
Recent attacks on Web servers running IIS have emphasized the need for better security precautions. For example, in May 2001, intruders defaced thousands of Web sites (including some OWA servers) by using simple HTTP to take advantage of an IIS weakness. This IIS weakness was known and documented, but many administrators failed to apply the proper hotfixes. Here are some suggestions to help you tighten security on your OWA 2000 and IIS servers:
- Apply Windows 2000 SP2.
- Apply the cumulative patch in Microsoft Security Bulletin MS01-044. This patch includes all the hotfixes for IIS up to August 2001. You should also apply all other relevant hotfixes that were released after the cumulative patch. To obtain the hotfixes, go to the Microsoft Security Web site (http://www.microsoft.com/security) and click the Security Bulletins link.
- If you're using Exchange 2000 without SP1, see the Microsoft article "XGEN: Incorrect Attachment Processing in Exchange 2000 Outlook Web Access Can Run Script" (http:// support.microsoft.com/support/kb/articles/q299/5/35.asp) for information about a hotfix you should apply.
- Remove the IISSamples, IISHelp, and MSADC sample virtual directories.
- Remove unnecessary and unused services, such as the FTP Server service, Windows Media Services, and Simple TCP/IP Service.
- Disable the Win2K Telnet server.
Another recommended precaution is moving the command-line tools that intruders might use from the \winnt\system32 directory to another directory. Before you can begin this process, though, you must disable Windows File Protection (WFP), a feature that's part of Win2K's System File Checker (SFC) utility. Microsoft designed WFP to protect .dll and .exe files in the \winnt\system32 directory. WFP automatically replaces any files that you delete or overwrite from this directory. To disable WFP, open a registry editor and locate the HKEY_ LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ Winlogon subkey. To disable the SFC utility, change the SFCDisable value to 1 and close the registry editor. For more information about this registry change, see the Microsoft article "Registry Settings for Windows File Protection" (http://support.microsoft.com/ support/kb/articles/q222/4/73.asp).
After you disable the SFC utility, you can move the command-line tools. Create a directory named \winnt\systools, and assign only the Administrators group NTFS permissions to this directory. Move the following files from the \winnt\system32 directory into the \winnt\systools directory: cmd .exe, ftp.exe, wscript.exe, cscript.exe, net.exe, xcopy.exe, rsh.exe, rcp.exe, rexec.exe, regedt32.exe, regedit.exe, and cacls.exe. Note that when you apply any Win2K service pack, these files might be replaced and you'll need to remove them again.
If you don't want to disable WFP, you can change the permissions for these command-line tools. Give only the Administrators group and System account permission to read and execute these tools.
These measures are only some of the security precautions you can take. For a complete checklist of steps you can take to make your IIS server more secure, see the Microsoft Security Web site's Tools & Checklists section.
A Notable Improvement
OWA 2000's functionality is a notable improvement in Exchange 2000. When you configure OWA 2000 properly, it's a highly scalable and highly secure way to remotely access email and Exchange server functions.