Forms-Based Authentication in OWA 2003

Exchange Server 2003 Outlook Web Access (OWA) supports forms-based authentication technology. Also known as cookie authentication, this feature circumvents the risks associated with the common human frailty of either forgetting to log off or not logging off correctly and the inherent problems with browsers caching user credentials. Because improper logoffs and cached user credentials can leave your systems vulnerable to unauthorized users, many companies have been reluctant to enable OWA. With the instructions I provide here, you can enable forms-based authentication for your OWA deployment and reduce the security risks associated with such a deployment.

The Problem
OWA is a Web-based application that uses HTTP to let client browsers communicate with Exchange. OWA encapsulates requests and responses in HTTP messages, which, in their simplest form, consist of three parts: the type of request or response, host headers that qualify the request or response, and the message body. The browser takes appropriate action—displaying the body of the message, redirecting to a different URL, or challenging the user for credentials before resending the request—according to the response the browser receives from the server.

HTTP is a stateless protocol and effectively requires that each request contains user credentials in the form of an authentication host header. That header's format will depend on the types of authentication (e.g., Anonymous, Basic, Digest, Windows Integrated Authentication, Microsoft .NET Passport) that the Web-based application can support. The following steps represent a simple Basic authentication dialog between a client browser and a Web application (e.g., OWA) running on Microsoft IIS.

Step 6 is clearly necessary to make Web applications viable; no user wants to continually supply credentials for every HTTP request. However, credential caching is also fraught with security concerns because the browser caches the credentials for as long as the browser session remains open. This setup means that a user must close every window that he or she opened from the original browser session before the cached credentials are cleared.

Also, in Step 3, users can select a check box to remember their password so that when the logon page is next presented, the password field is already filled in. Although convenient for the end user, this option is obviously unsecure.

Gone are the days of information access from one locked-down desktop PC. Today's mobile information workers use a multitude of devices in a multitude of locations, offering plenty of opportunity for users to leave browsers active with credentials cached for subsequent use by those with prying eyes. Indeed, some locations, such as public kiosks, don't let users close the browser session.

The Solution
Forms-based authentication prevents users from selecting the Remember my password option on the standard browser window, makes the Logoff button 100 percent effective, and enables timeouts after periods of inactivity (such as when a user walks away from a public kiosk without logging off). Forms-based authentication performs these actions by intercepting and modifying the HTTP requests and responses before and after Exchange processes them. By manipulating the existence and content of the authentication host header, forms-based authentication technology lets you control how and when Exchange executes the request for user credentials. The technology performs this manipulation by using an Internet Server API (ISAPI) filter, an ISAPI extension, and a logon form (which is just a standard Active Server Pages—ASP—page) to gather user credentials.

This technology is also called cookie authentication because the technology uses a session cookie to store an encrypted form of users' credentials. The encrypted cookie data travels with each HTTP request, letting the ISAPI filter or extension retrieve the details and populate the authentication host header (or remove the header when a timeout occurs).

ISAPI Filters and Extensions
Forms-based authentication technology relies heavily on its ability to use ISAPI DLLs to extend IIS functionality. Two types of ISAPI DLLs exist—filters and extensions. A filter can examine and change the HTTP request-response flow coming into or out of a Web server or specific Web sites. Filters are therefore good for custom authentication and automatic redirect requests based on the headers of an HTTP message.

An extension is associated with a directory or Web site and delivers application-specific functionality when a particular file extension or HTTP verb is requested. Therefore, extensions work well for gathering custom data from back-end databases or, in the case of Exchange, data from the Exchange Store. Extensions are registered through application mappings, and on a back-end server you'll see the file extension * (i.e., all file extensions) and all HTTP verbs (e.g., Get, Post) for the Exchange and Public virtual directories mapped to davex.dll. That DLL contains the code that interacts with the Store and generates the relevant HTML to pass to a requesting client. Figure 1 shows mapping from a back-end Exchange 2003 server by using the Microsoft Management Console (MMC) Internet Information Services (IIS) Manager snap-in.

Setting Up the Environment
Forms-based authentication works most efficiently in a traditional front-end/back-end architecture. As you know, OWA is a Web application that runs on IIS and lets users access their Exchange mailbox and public folders through a Web browser. OWA is installed by default when you install Exchange 2000 Server or later. To support OWA, the installation creates several IIS virtual directories (e.g., Exchange, Public), which you can view through the IIS Manager snap-in. A user enters a URL into the browser's address field to specify the virtual directory associated with the application that he or she wants to run. IIS then invokes the application that the URL references. Invoking the application might mean executing some standard HTML or ASP code or invoking an ISAPI extension, as described above. For example, if I enter http://myserver/Exchange into my browser, IIS directs the request to the application associated with the Exchange virtual directory. By default, this application is contained in davex.dll, which interacts with the Store to retrieve and render the contents of my mailbox and pass the contents to my browser.

Because OWA is installed by default, a Web browser can interact directly with any Exchange 2000 or later server and have this server deliver mailbox or public folder content through the process I just described. However, you can choose to mark an Exchange server as a front-end server, which changes the way it reacts to URL requests. This setup is called a front-end/back-end server configuration; by implication, any server not marked as a front-end server is known as a back-end server.

Front-end/back-end configurations serve many purposes and allow more flexible and more secure implementations. These configurations are typically used for Secure Sockets Layer (SSL)­encrypted communications over the Internet. In a front-end/back-end configuration, the Web browser doesn't communicate directly with the Exchange server that renders the mailbox or public folder content. Instead, the browser communicates with the front-end server, which, in turn, proxies the request to a back-end server. The back-end server then gathers the necessary content and passes it to the front-end server, which passes the content back to the Web browser. The front-end server performs all the SSL processing and authentication requests, thus relieving the back-end server of such processing.

When you set up an Exchange server to function as a front-end server, some subtle changes happen in the IIS configuration. A front-end server performs different tasks than a back-end server does; the front-end server's main task is to proxy HTTP requests to back-end servers. Marking an Exchange server as a front-end server replaces the default ISAPI extension, davex.dll, with an extension called exprox.dll, as Figure 2 shows.

The second change that occurs is in the authentication methods that the Exchange virtual directories support. A back-end server supports Integrated Windows Authentication and Basic authentication, but only Basic is allowed on a front-end server because the front-end server must be able to authenticate to the back-end server as the requesting client. Therefore, the front-end server must be able to present the user's credentials in an authentication host header in a way that's compatible with the methods the back-end server accepts.

To present the user's information, the front-end server would need to know the user's password, and Windows NT LAN Manager (NTLM—the method negotiated through Integrated Windows Authentication) doesn't involve the exchange of a password between the client and server—only a hash of the user's password is exchanged. Thus, if Integrated Windows Authentication were enabled on a front-end server, the server would have no way to determine the user's password and wouldn't be able to respond to any challenges from the back-end server. Basic authentication involves the exchange of the user's base64-encoded password, so the front-end server can respond to any authentication method that the back-end server supports as if the front-end server were the actual client.

Clearly, Basic authentication poses a security threat because decoding base64 is easy. Security best practice dictates that you use SSL to protect front-end servers. In fact, forms-based authentication requires the use of SSL to prevent a network sniffer from intercepting user credentials.

Enabling Forms-Based Authentication
You enable forms-based authentication through the MMC Exchange System Manager (ESM) snap-in. Open ESM, then navigate to and open your server. Click Protocols, HTTP, then right-click Exchange Virtual Server to view its Properties. Select the Settings tab, which lets you enable forms-based authentication.

Enabling forms-based authentication makes changes to the IIS configuration that enables registration of the ISAPI filter in exchsrvrexchwebbinauthowaauth.dll. This filter is registered in the Default Web Site Properties dialog box, which Figure 3, page 4, shows. This ISAPI filter registers only for HTTP Secure (HTTPS) traffic, which is what makes SSL mandatory for forms-based authentication to function.

Enabling forms-based authentication also sets the default domain to "" on the Exchange virtual directory to permit user principal name (UPN) logons. UPN logons remove the need for users to supply their domain name when supplying credentials; thus, UPN logons provide a more user-friendly authentication method—particularly in an ISP/application service provider environment in which users wouldn't necessarily know their account's domain name. Many organizations set their users' UPN logon to be the same as their email address. Note that although the logon form asks for a domain and username, forms-based authentication supports UPN logon.

Last, the exchwebbinauth folder is enabled as a virtual directory with Anonymous access enabled, and the owalogon.asp file contained in that folder is set as the default document. This setup lets you anonymously redirect Access Denied responses to the logon page.

Flow of Operation
Let's look at what happens when a user logs on to a front-end server that has been enabled for forms-based authentication and see how the various components come into play. The basic idea is that the user's credentials are contained in a cookie attached to each HTTP message. The ISAPI extension uses an ever-changing symmetric key to encrypt the data associated with the cookie. The front-end server attempts to decrypt the cookie with the current key, pull out the credentials, and attach them to the message's authentication header. Any failure to decrypt the cookie (e.g., if the key has changed, indicating a timeout) or nonexistence of the cookie redirects the incoming request to the logon page.

Note that all processing associated with the generation of symmetric keys, cookie handling, and encryption/decryption is performed on the server that you've enabled for forms-based authentication. Therefore, in a typical implementation, only the front-end server performs these tasks. The back-end server has no knowledge of what's happening on the front end and just sees typical, authenticated requests that the front-end server proxies.

To illustrate this flow of operation and how the various components work together, let's look at two logon scenarios. For simplicity, let's assume we have one front-end server called FE and one back-end server called BE.

Scenario 1. In the first scenario, the user enters https://fe/exchange into the browser's Address field for the first time.

The next scenario we'll look at illustrates what happens when a user doesn't perform any operation within a specified window of time. The next operation the user tries to perform will present the logon page. Before I explain how this process occurs, it's important to note that the front-end server maintains knowledge of three symmetric keys—the current key and the previous two keys. In fact, there are two sets of these three keys—one set for Public access and one set for Trusted access. The reason for having two sets is to provide different timeouts for accessing OWA through a public computer (e.g., a kiosk) and from a private location such as a home office.

You can control the desired timeout values by modifying the REG_DWord values PublicClientTimeOut and TrustedClientTimeOut in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMsExchangeWebOWA registry subkey on the front-end server. These values are expressed in minutes, with a default timeout of 15 minutes for a public client and 1440 minutes (24 hours) for a private client.

The server regenerates a symmetric key at a frequency of half the desired timeout value, which means that the actual timeout will occur between 1 and 1.5 times the desired timeout value. For example, let's say you set a timeout value of 30 minutes. Every 15 minutes, the server will generate a new key and, therefore, a key will exist on the server for a maximum of 45 minutes.

When the ISAPI filter creates the cookie (see Scenario 1, Step 7) and adds the encrypted base64 credentials to it, the filter also adds the current key number and session ID. We can see this in the cookie header that Figure 4 shows. This header came from a network trace for Step 7.

The cadata string starts with the index number of the key that was used for the encryption and will be a value of 0, 1, or 2. A value of 2 indicates the current key. In the example that Figure 4 shows, the value 1 means the previous key was used. Let's look at the following scenario to see how timeouts work.

Scenario 2. In the second scenario, a user remains idle for longer than the timeout period, then tries to open the Calendar folder. This action generates an HTTP request to the server for http://fe/exchange/user/calendar?cmd=contents.

The two scenarios I've presented here will help you understand the authentication process and how forms-based technology can help secure this process. Be sure to read the Web-exclusive sidebar "Forms-Based Authentication: Problems and Points Worth Noting" (http://www.winnetmag.com/microsoftexchangeoutlook, InstantDoc ID 40821) for a few caveats to remember when deploying the technology in your environment.

Moving Forward
Lack of a secure logoff method is one of the main stumbling blocks when corporations consider opening up Exchange to external access through OWA. Forms-based authentication goes a long way in mitigating this problem and should encourage more enterprises to embrace such a deployment.