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_MACHINE\SYSTEM\CurrentControlSet\Services\MsExchangeWeb\OWA 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 ISAPI filter intercepts the request and determines whether a cookie is attached. In this case, the request has a cookie.
- The filter extracts from the cookie the index number of the symmetric key used to encrypt the data. Note that this isn't the actual symmetric key, just the index number of the key.
- The filter retrieves the current key associated with this index number and uses it to decrypt the data. Remember that the server is maintaining three keys and generates a new one after each key interval. Thus, the keys associated with each index position change as well.
- In this case, decryption fails because the key that's associated with the index position is no longer the same key that was in that position when encryption originally occurred.
- The ISAPI filter strips off the cookie and passes the HTTP request to the Exchange server.
- We're now in the same situation as Scenario 1, Step 1.
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.