Chapter 19: Supporting OutlookWeb Access

This chapter focuses on Microsoft Outlook Web Access (OWA). Because the need for remote access to e-mail has greatly increased, use of OWA will also only increase as time goes by. Understanding the advantages and limitations of OWA will benefit your planning, implementation, and troubleshooting efforts. In the following sections, we’ll examine the new OWA features in Microsoft Exchange Server 2003, how to manage OWA, and how to deploy this technology. There is much here to discuss, so let’s get started.

Features of OWA

OWA provides an environment for users to access both public folder store data and mailbox store data using a browser. With OWA, clients based on UNIX, Macintosh, and Microsoft Windows can view and work with any public folder, mailbox, Global Address List (GAL), and calendar. (For UNIX users, OWA is the primary Outlook solution for e-mail, calendar, and collaboration functionality.)

Among the many navigation, view, and workflow improvements that have an impact on performance and functionality of OWA in Exchange Server 2003 are the following:

• Two different versions of OWA

• New customized logon page

• Cookie-based validation in which the OWA cookie is invalid after the user logs out or becomes inactive for a configured period of time

• Starting with Microsoft Internet Explorer (IE) 6 with Service Pack 1, the credentials cache is cleared after logout

• Better user interface

• User-configured window size that persists during an OWA session

• Preview pane can be to the right of messages and attachments that are open directly in the pane

• Spelling checker is provided for e-mail messages

• Server-based e-mail handling rules that are created and managed by the user

In spite of all these new features, OWA does retain some limitations. Therefore, before you deploy OWA, you must consider what will not be accommodated:

• Offline use A user must connect to an Exchange server to view information.

• No access to offline folders There is no synchronization of local offline folders with server folders.

Logon/Logoff Improvements

You can enable a new logon page for OWA that will store the user’s user name and password in a cookie instead of in the browser. When the user leaves his OWA session or after a configured period of inactivity, the cookie is cleared. In either scenario, a user must re-authenticate to use OWA again. Note that the sessions do not timeout during the creation of a message.

This logon improvement is not enabled by default. To enable the logon page, open the properties of the HTTP Virtual Server and select the Enable Forms Based Authentication For Outlook Web Access check box (Figure 19-1). Note that before you can use this feature, you must have Secure Sockets Layer (SSL) configured in Microsoft Internet Information Services (IIS).

Figure 19-1: Enabling logon authentication.

To configure SSL, you must either install Certificate Services on your Windows Server 2003 and generate a certificate for the OWA Web site, or purchase an SSL certificate from a third-party source. After you install the SSL certificate and require SSL on your Web site that is hosting OWA, you will be presented with the new logon screen shown in Figure 19-2.

Figure 19-2: Exchange 2003 OWA logon screen.

The new logon improvement has three other features. First, users cannot accidentally enable the Remember My Password check box. Also, when the user logs off, the user has no way to access her inbox unless she re-authenticates. Finally, the OWA toolbars and graphics are downloaded in a hidden frame during the logon process to give a peppier logon experience to the user.

Notice that during the logon process, the user can choose from two interface experiences: Rich and Basic. The Rich experience includes all OWA features. The Basic experience does not and is meant for users who are connecting over a slow wide area network (WAN) link and need only the essentials of OWA. For users with faster connection speeds, the Rich experience is preferred.

As an administrator, you can configure the registry of the OWA for timeout settings. Think also in terms of a public computer and a trusted computer. A public computer is one that is available to the general public, for instance, a kiosk in a public area that supplies OWA. If the Public setting is selected, the timeout will be set to 15 minutes. This timeout setting can be overridden by a server-side registry setting:

Location: ] HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeWEB\OWA Parameter: PublicClientTimeout Type: REG_DWORD Value: <number of minutes> 

This registry key assumes a 15-minute timeout setting. The minimum value is 1, and the maximum value is 43200 (30 days).

The trusted computer setting is meant for those computers that sit on your internal network. The default value for this setting is assumed to be 1440 minutes, or 24 hours. If you want to change this setting, use the same registry key you would for the Public computer but use the parameter TrustedClientTimeout. The minimum and maximum values for PublicClientTimeout and TrustedClientTimeout are the same.

You need to know about some issues with the timeout setting. First, the cookie- based timeout setting is not absolute—it triggers between the value of the setting and 1.5 <setting>. In other words, if you set the timeout value as 10 minutes, the timeout actually triggers between 10 and 15 minutes (10 1.5 = 15). Since the default setting for the trusted computer is 1440 minutes, the actual timeout will trigger somewhere between 1440 and 2160 minutes, or 24–36 hours. Such a wide window for a timeout trigger might not be compatible with your security policies. Unfortunately, the formula is not configurable, so you might be forced to lower the default value on trusted computers if your information security policies dictate this.

The second issue you need to be aware of is that the TrustedClientTimeout setting cannot be lower than the PublicClientTimeout setting. Even when you set the trusted value lower than the public value, Exchange 2003 will automatically adjust the trusted value to be equal to the public setting. This automatic configuration change will kick in regardless of which value you incorrectly set. So whether you set the trusted value too low or the public value too high, you’ll end up with the trusted value being automatically set to be equal to the public value.

Another security feature implemented in Exchange 2003 OWA is that by default, the user cannot change his password. If you upgrade from Microsoft Exchange 2000 to Exchange 2003, the Exchange 2000 setting that allows users to change passwords will be retained. You can set this parameter in the Exchange server’s registry:

Key:  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeWEB\OWA Parameter:  DisablePassword Type: REG_DWORD Value:  0x0000001= users cannot change passwords, 0x00000000=users can change     passwords

Securing Outlook Web Access Client Traffic

To secure the transmission of messages between Exchange 2003 OWA and a client, you must decide how to authenticate the client and whether you want client traffic encrypted or signed.

You can authenticate your client in one of three ways: Anonymous, Basic, and Integrated Windows. The Anonymous setting is the least secure authentication scheme, providing limited access for specific public folders and directory information. Anonymous authentication is supported by all clients and is the preferred method of allowing general public access to specific public folders.

Basic authentication uses clear text to authenticate the client with a domain controller. Basic authentication requires the user to enter the user name, the domain name, and the password. Because the user name and password are sent in clear text between the server and the client, using SSL to encrypt the user name and password is recommended to ensure safer transmissions.

Integrated Windows Authentication (IWA) is meant for clients running Internet Explorer 5 or later. IWA uses Kerberos to perform authentication and offers the highest level of security. In IWA, the user’s password is not sent on the line in clear text. Instead it is encrypted so that even when the password’s packets are sniffed, the attacker cannot read the password. We’ll discuss how to implement these concepts later in this chapter in the section titled “Deploying OWA.”