Configuring Form-Based Authentication for OWA 2003

Problem

You want to enable form-based authentication (FBA) for your OWA 2003 servers.

Solution

Using a graphical user interface

1. Open the Exchange System Manager (Exchange System Manager.msc).
2. In the left pane, expand the appropriate Administrative Groups container and expand the Servers container.
3. Expand the target server and expand its Protocols container.
4. Expand the HTTP node, then right-click the Exchange Virtual Server object and choose Properties.
5. Switch to the Settings tab.
6. Click the Enable Forms Based Authentication checkbox.
7. Optionally, select a compression method from the Compression pulldown. (See the Discussion section for more on compression.)
8. Click OK.
9. ESM will display a warning dialog telling you that FBA requires SSL. Click OK.
10. Restart IIS by opening a command window and using the iisreset command.

Discussion

The idea behind FBA is simple, but understanding it requires some background. If you've used the Exchange 5.5 version of OWA, you probably remember its logon form, which was embedded in an HTML page. The Exchange 2000 version of OWA did away with this logon page; instead, when you try to log on to Exchange, your browser would prompt for logon credentials. In Exchange Server 2003, you get to choose the approach you preferbut which one is better? The difference between these two approaches is significant but subtle.

When a web browser gets an authentication request from a server, it has to ask the user for credentials. After the user types his credentials in, the browser could make him type them over and over again for subsequent pages; instead, browsers cache the credentials and send them for each subsequent page. This is easy for the user, but it raises some potential security problems. If the credentials are protected using basic authentication, an attacker could easily capture them from an unencrypted connection. Even if the connection is encrypted, there's no good way to force the browser to "forget" the credentials after a set time period has passedleading to the sadly common situation where user A logs on to OWA, leaves the machine, and has user B come along and continue their OWA session.

FBA attacks this problem by eliminating the browser's access to credentials. When you use the OWA 2003 logon page, your credentials are sent as form fields to the Exchange server, but the communication is protected by SSL (which is why FBA requires SSL). The user name and password arrive at the server, which uses them to authenticate you against the Exchange mailbox you've requested access to. If the authentication request succeeds, the OWA server sends an encrypted cookie back to your browser. The browser supplies the cookie on each subsequent page reload, and the server can decrypt it and see if it's valid. Net result: credentials are only sent once, and the rest of the time the cookie is passed from client to server. Better still, the server controls the contents of the cookie, so it can include a time stamp. By checking the time-stamp value each time the cookie is presented by the browser, it's possible to set session time limits, once the timestamp indicates that the cookie has expired, the server redirects the user to the logon page to get a new cookie.

Changing OWA 2003 Session Timeouts

Problem

You want to adjust the time out for OWA 2003 user's session.

Solution

Using a graphical user interface

1. Log on to the OWA server.
2. Open the Registry Editor (regedit.exe).
3. Select the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSEx-changeWeb\OWA registry key.
4. Choose New DWORD Value from the Edit menu.
5. Name the new value PublicClientTimeout.
6. Double-click PublicClientTimeout and set its value to the number of minutes after which you want a logon session from a public client to time out. The default value is 15 minutes, but you can assign any value between 0 and 43,200 minutes.
7. Choose New DWORD Value from the Edit menu.
8. Name the new value TrustedClientTimeout.
9. Double-click TrustedClientTimeout and set its value to the number of minutes after which you want a logon session from a trusted client to time out. The default value is 1440, with a permissible range of 0 to 43200.
10. Stop and restart the WWW publishing service.

Using a command-line interface

The following commands set the timeout to 30 minutes:  > reg add HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA      /t REG_DWORD /v "PublicClientTimeout" /d 30  > reg add HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA      /t REG_DWORD /v "TrustedClientTimeout" /d 30
  > net stop w3svc  > net start w3svc

Using VBScript

' This code sets the public and private machine timeouts for OWA 2003  ' ------ SCRIPT CONFIGURATION ------  strOWA = "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeWeb\OWA\"  ' ------ END CONFIGURATION ---------    Set objWSH = wscript.CreateObject("WScript.Shell")  objWSH.RegWrite strOWA & "PublicClientTimeout", 5, "REG_DWORD"  WScript.echo "Public machine timeout set to 5 minutes."  objWSH.RegWrite strOWA & "TrustedClientTimeout", 30, "REG_DWORD"  WScript.echo "Private machine timeout set to 30 minutes."

Discussion

When you use FBA, as described earlier, the server generates a timestamped, encrypted cookie that it can use to determine when the user's OWA session should time out. OWA 2003 distinguishes between trusted clients, which are presumably secure, and public clients, which are machines (like airport kiosks or public-access terminals in hotels) that can't necessarily be trusted. There are separate timeout values for each of these client types, controlled by the two registry values previously described. Of course, since OWA can't tell what kind of client it's running on, the ultimate selection of a client type comes from the radio buttons on the OWA logon page: clicking Public or shared computer tells OWA to apply the public client timeout value, and clicking Private computer causes the trusted client timeout to apply.