Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2008-11-24

This topic explains forms-based authentication for Microsoft Office Outlook Web Access in Microsoft Exchange Server 2007. Forms-based authentication enables a logon page for Outlook Web Access that uses a cookie to store a user's encrypted logon credentials in the Internet browser. Tracking the use of this cookie enables the Exchange server to monitor the activity of Outlook Web Access sessions on public and private computers. If a session is inactive for too long, the server blocks access until the user re-authenticates.

Using Cookies to Control Access

The first time that the user name and password are sent to the Client Access server to authenticate an Outlook Web Access session, an encrypted cookie is created that is used to track user activity. When the user closes the Internet browser or clicks Log Off to log off their Outlook Web Access session, the cookie is cleared. The user name and password are sent to the Client Access server only for the initial user logon. After the initial logon is complete, only the cookie is used for authentication between the client computer and the Client Access server.

Setting the Value for Cookie Time-Out on Public Computers

By default, when a user selects the This is a public or shared computer option on the Outlook Web Access logon page, the cookie on the computer expires automatically and the user is logged off after they have not used Outlook Web Access for 15 minutes.

Automatic time-out is valuable because it helps protect users' accounts from unauthorized access. To match the security requirements of your organization, you can configure the inactivity time-out values on the Exchange Client Access server.

Although automatic time-out greatly reduces the risk of unauthorized access, it does not eliminate the possibility that an unauthorized user might access an Outlook Web Access account if a session is left running on a public computer. Therefore, make sure that you warn users to take precautions to avoid risks, such as by telling them to log off from Outlook Web Access and close the Web browser when they have finished using Outlook Web Access.

For more information about how to configure cookie time-out values for public computers, see How to Set the Forms-Based Authentication Public Computer Cookie Time-Out Value.

Setting the Value for Cookie Time-Out on Private Computers

When a user selects the This is a private computer option on the Outlook Web Access logon page, the Exchange server allows a longer period of inactivity before automatically ending the Outlook Web Access session. The default time-out value for private logon is eight hours. The private computer cookie time-out option is intended to benefit Outlook Web Access users who are using their own computer or a computer that is on a corporate network. 

It is important to warn users about the risks that are associated with selecting the This is a private computer option. A user should select the private computer option only if they are the sole operator of the computer and the computer complies with the security policies for your organization.

For more information about how to configure cookie time-out values for private computers, see How to Set the Forms-Based Authentication Private Computer Cookie Time-Out Value.

Determining User Activity

After an Outlook Web Access session has been inactive for a certain period of time, the Client Access server no longer has the decryption key to read the cookie and the user will be denied access until they authenticate again.

Exchange 2007 uses the following information to determine user activity:

  • Interaction between the client computer and the Client Access server that is initiated by the user is considered activity. For example, if a user opens, sends, or saves an item; switches folders or modules; or updates the view or the Web browser window, Exchange 2007 considers this to be activity.

    Note:
    Interaction between the client computer and the server that is automatically generated by the Client Access server is not considered activity. For example, new e-mail notifications and reminders that are generated by the Client Access server in an Outlook Web Access session are not considered activity.
  • In Outlook Web Access Light any user activity other than entering text is considered activity. In Outlook Web Access Premium, any user interaction, including entering text in an e-mail message or meeting request, is considered activity.

Configuring the Logon Prompt That is Used by Forms-Based Authentication

Instead of a pop-up window, forms-based authentication creates a logon page for Outlook Web Access. You can configure the text of the logon prompt that is given by forms-based authentication by using the Exchange Management Console or the Exchange Management Shell. The configuration changes that you make change only the text of the logon prompt. They do not change the format in which the user must log on. For example, you can configure the forms-based authentication logon page to prompt users to provide their logon information in the format domain\user name. However, a user can also enter his or her user principal name (UPN) and the logon will be successful.

The following types of logon prompts can be used by forms-based authentication on the Outlook Web Access logon page. Select the prompt that will be easiest for your users to understand and use.

  • FullDomain   The domain and user name of the user in the format domain\user name. For example, Contoso\Kweku.

  • PrincipalName   The UPN. The UPN has two parts: the UPN prefix that is the user account name and the UPN suffix that is the DNS domain name. The prefix and the suffix are joined by the at (@) sign to make the complete UPN. For example, Kweku@contoso.com. Users can access Outlook Web Access by entering their primary e-mail address or by entering their UPN.

  • UserName   The user name only. The domain name is not included. For example, Kweku. This logon format will work only if the domain name has been configured.

    Note:
    If necessary, you can change the format the user must use to log on to Outlook Web Access by configuring the Active Directory directory service and Internet Information Services (IIS). Using Active Directory and IIS to set which user name formats users can enter to be authenticated is independent of the Outlook Web Access forms-based authentication prompt discussed earlier.

Understanding Encryption for User Logon from Public and Private Computers

Encryption of user logon credentials for both public and private Outlook Web Access logon types involves a set of six hashed message authentication codes (HMACs). HMACs are 160-bit keys that are generated on the Client Access server. HMACs improve logon security by combining hashing algorithms with cryptographic functions to encrypt user logon credentials. Encryption and decryption of a cookie are performed by the same Client Access server. Only the Client Access server that generated the authentication key has the key to decrypt that cookie.

When forms-based authentication for Outlook Web Access is used, the Client Access server cycles through a set of three keys for each type of logon, public and private, at a set rate. This is known as the recycle time. The recycle time for a key is one half of the time-out value for the logon. For example, when the time-out value for the public logon is set to 15 minutes, the public key recycle time is 7.5 minutes. 

The six logon keys are created by the Client Access server when the Outlook Web Access virtual directories are started. Three are used with public computer logons, and three are used with private computer logons. When a user logs on, the current key for their logon type is used to encrypt the user's authentication information into a cookie.

When the recycle time has passed, the Client Access server moves to the next key. After all three keys for a type of logon have been used, the Client Access server deletes the oldest key and creates a new one. The Client Access server always keeps three keys available for each logon type: the current key and the two most recent keys. The recycling of keys continues as long as Outlook Web Access is running on the Client Access server. The same keys are used for all users.

Any cookie that has been encrypted by using an active key will be accepted. When a user activity request is received by the Client Access server, the cookie for that request is replaced with a new cookie that has been encrypted by using the newest key. A user session is timed out when the cookie associated with it is encrypted by an older key that has been discarded.

Because of the relationship between the recycle time of encryption keys and user time-out configured on the server, the actual time-out period for a user can be between the configured time-out and the configured time-out plus one-half of that value. For example, if the configured time-out is 30 minutes, the actual time-out for any user session may be between 30 minutes and 45 minutes.

Table 1 provides information about the cookie time-out and authentication key recycling time based on a user logon from a public or private computer.

Table 1   Default cookie time-out and authentication key recycling time for each user logon type

Logon Cookie time-out value Recycle time for authentication key if you use the default time-out value

Public

One minute to 30 days. The default is 15 minutes.

7.5 minutes

Private

One minute to 30 days. The default is 8 hours.

4 hours
Note:
You can configure the cookie time-out value in minutes by using the registry. The recycle time of the authentication key is at least one-third, and not more than one-half, that of the cookie time-out value.

Using SSL to Help Secure Outlook Web Access

By default, Secure Sockets Layer (SSL) encryption is turned on when you install the Client Access server role. If SSL is not used, the user name and password will be sent in clear text at initial logon. When SSL is used, it encrypts all communications between the client computer and the Client Access server and helps prevent sensitive information, such as user names, passwords, and e-mail messages, from being viewed by third parties.

A default SSL certificate is installed with the Client Access server role, but is not trusted. If you use the default SSL certificate, it must be trusted or a prompt will appear that asks users whether they trust the certificate every time that they log on to Outlook Web Access. For information about how to use the default SSL certificate, see How to Trust the Default SSL Certificate. 

For More Information