Configuring Forms-Based Authentication for Outlook Web App

Applies to: Exchange Server 2010

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

Contents

Using Cookies to Control Access

Determining User Activity

Configuring the Sign-in Prompt That Is Used by Forms-Based Authentication

Understanding Encryption for User Sign-in from Public and Private Computers

Using SSL to Help Secure Outlook Web App

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 App session, an encrypted cookie is created that's used to track user activity. When the user closes the Internet browser or clicks Sign Out to sign out of their Outlook Web App session, the cookie is cleared. The user name and password are sent to the Client Access server only for the initial user sign-in. After the initial sign-in 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 App sign-in page, the cookie on the computer expires automatically and the user is signed out when they haven't used Outlook Web App 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 doesn't eliminate the possibility that an unauthorized user might access an Outlook Web App account if a session is left running on a public computer. Therefore, make sure to warn users to take precautions to avoid risks. For example, tell them to sign out from Outlook Web App and close the Web browser when they've finished using Outlook Web App.

For more information about how to configure cookie time-out values for public computers, see 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 App sign-in page, the Exchange server allows a longer period of inactivity before automatically ending the Outlook Web App session. The default time-out value for private sign-in is twelve hours. The private computer cookie time-out option is intended to benefit Outlook Web App users who are using their own computer or a computer that's on a corporate network.

It's important to warn users about the risks 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 Set the Forms-Based Authentication Private Computer Cookie Time-Out Value.

Return to top

Determining User Activity

After an Outlook Web App 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 2010 uses the following information to determine user activity:

• Interaction between the client computer and the Client Access server that's 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 2010 considers this to be activity.

  Note

  Interaction between the client computer and the server that's automatically generated by the Client Access server isn't considered activity. For example, new e-mail notifications and reminders that are generated by the Client Access server in an Outlook Web App session aren't considered activity.

• In Outlook Web App, any user interaction, including entering text in an e-mail message or meeting request, is considered activity. In the light version of Outlook Web App, any user activity other than entering text is considered activity.

Configuring the Sign-in Prompt Used by Forms-Based Authentication

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

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

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

• **Principal Name   **The UPN. The UPN has two parts: the UPN prefix that's the user account name and the UPN suffix that's 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 App by entering their primary e-mail address or by entering their UPN.

• **User Name   **The user name only. The domain name isn't included. For example, Kweku. This sign-in format will work only if the domain name has been configured.

  Note

  If necessary, you can change the format the user must use to sign in to Outlook Web App by configuring Active Directory 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 App forms-based authentication prompt discussed earlier.

Return to top

Understanding Encryption for User Sign-in from Public and Private Computers

Encryption of user sign-in credentials for both public and private Outlook Web App sign-in types involves a set of six Hashed-based Message Authentication Codes (HMACs). HMACs are 160-bit keys that are generated on the Client Access server. HMACs improve sign-in security by combining hashing algorithms with cryptographic functions to encrypt user sign-in 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 is used, the Client Access server cycles through a set of three keys for each type of sign-in, 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 sign-in. For example, when the time-out value for the public sign-in is set to 15 minutes, the public key recycle time is 7.5 minutes.

The six sign-in keys are created by the Client Access server when the Outlook Web App virtual directories are started. Three are used with public computer sign-ins, and three are used with private computer sign-ins. When a user signs in, the current key for their sign-in 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 sign-in 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 sign-in type: the current key and the two most recent keys. The recycling of keys continues as long as Outlook Web App 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's 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's 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.

The following table provides information about the cookie time-out and authentication key recycling time based on a user sign-in from a public or private computer.

Default cookie time-out and authentication key recycling time for each user sign-in type

Return to top

Using SSL to Help Secure Outlook Web App

By default, Secure Sockets Layer (SSL) encryption is turned on when you install the Client Access server role. If SSL isn't used, the user name and password will be sent in clear text at initial sign-in. 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.

Return to top