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.