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.
- When a user enters a URL into the browser, the browser sends an HTTP message requesting a Web page to the server. The HTTP message has no authentication host header at this point.
- The server returns a 401 Access Denied error message and sends an HTTP response message that tells the browser the authentication methods the application supports (in this case, Basic authentication).
- The browser reacts to the Basic authentication challenge by presenting the user with a logon dialog box requesting the username, password, and domain.
- The browser uses base64 to encode these details, adds them as an authentication host header to the original HTTP request, then resends the request.
- The server checks the validity of the credentials. If the credentials are valid, the server returns the requested Web page; otherwise, it returns another 401 Access Denied error message.
- The browser caches the credentials and adds the credentials to subsequent HTTP requests as required so that it doesn't need to prompt the user for credentials at each request.
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.