Understanding Authentication for Outlook Web App
Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
This topic explains the types of authentication that are available for Outlook Web App in Microsoft Exchange Server 2010. The authentication method that's best for your organization depends on your organization's security needs. By default, Outlook Web App uses forms-based authentication and is configured to use Secure Sockets Layer (SSL) encryption.
Forms-Based Authentication
Forms-based authentication enables a sign-in page for 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.
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 from 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.
For more information about forms-based authentication and how to configure it, see:
Single Sign On for Outlook Web App and Exchange Control Panel
To support single sign on between Outlook Web App and Exchange Control Panel, a new service, the Exchange FBA Authentication service, is available in Exchange 2010. To use this new feature, ensure that the authentication mode for both Outlook Web App and Exchange Control Panel virtual directories is set to forms-based authentication.
Setting the Value for Cookie Time-Out
The cookie time-out is set based on the user's choice of either the This is a public or shared computer option or the This is a private computer option on the Outlook Web App sign-in page. By default, the cookie on the computer expires automatically and the user is signed out after they haven't used Outlook Web App for between 15 and 22.5 minutes if they've selected the public computer option, and after they haven't used Outlook Web App for between eight and twelve hours if they've selected the private computer option.
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 completely eliminate the possibility that an unauthorized user might access an Exchange mailbox 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 sign out from Outlook Web App and close the Web browser after they've finished using Outlook Web App.
For more information about how to configure the cookie time-out values for public and private computers, see:
Set the Forms-Based Authentication Public Computer Cookie Time-Out Value
Set the Forms-Based Authentication Private Computer Cookie Time-Out Value
Return to top
Standard Authentication Methods
In Exchange 2010, Client Access servers support Integrated Windows authentication and HTTP 1.1 Digest authentication for Exchange 2010 virtual directories.
For more information about standard authentication methods, see Setting Up Standard Authentication Methods for Outlook Web App.
Basic Authentication
Basic authentication is a simple authentication mechanism that's defined by the HTTP specification that encodes a user's sign-in name and password before the user's credentials are sent to the server.
Basic authentication doesn't support single sign-on. Windows Server 2008 and Windows Server 2003 authentication enable single sign-on to all network resources. With single sign-on, a user can sign in to the domain one time by using a single password or smart card and authenticate to any computer in the domain.
Basic authentication is supported by all Web browsers, but is not secure unless you require SSL encryption.
For more information about how to configure Basic authentication on an Outlook Web App virtual directory, see Configure Basic Authentication.
Digest Authentication
Digest authentication transmits passwords over the network as a hash value for additional security. Digest authentication can be used only in Windows Server 2008, Windows Server 2003, and Microsoft Windows 2000 Server domains for users who have an account that's stored in Active Directory. For more information about Digest authentication, see the Windows Server 2003 and Internet Information Services (IIS) Manager documentation.
Digest authentication is available only on Exchange 2010 virtual directories.
Important
If you're using Digest or Basic authentication, when a user uses a kiosk, caching credentials can pose a security risk if the user doesn't close the browser and end the browser process between sessions. This risk occurs because a user's credentials remain in the cache when the next user accesses the kiosk. To enable Outlook Web App on a kiosk, make sure that the user can close the browser between sessions and end the browser processes. Otherwise, consider using a third-party product that incorporates two-factor authentication, in which the user must present a physical token together with a password to use Outlook Web App on a kiosk.
For more information about how to configure Digest authentication on an Outlook Web App virtual directory, see Configure Digest Authentication.
Return to top
Integrated Windows Authentication
Integrated Windows authentication requires that users have a valid Windows Server 2008, Windows Server 2003, or Windows 2000 Server user account name and password to access information. Users signed in to the local network aren't prompted for their user names and passwords. Instead, the server negotiates with the Windows security packages that are installed on the client computer. This method enables the server to authenticate users without prompting them for sign-in information. The authentication credentials are protected, but all other communication will be sent in clear text unless SSL is used.
Microsoft Internet Explorer allows single sign-on for Web applications that include Outlook Web App Web Parts if the server that's being accessed has Integrated Windows authentication enabled. Users must enter credentials only one time for each browser session. However, their credentials are cached in the browser process.
On an Exchange 2010 server on which only the Client Access server role is installed, Integrated Windows authentication can be used only with Exchange 2010 virtual directories. On a server that has both the Client Access and Mailbox roles installed, Integrated Windows authentication can be used with any virtual directory. For more information about Integrated Windows authentication, see the Windows Server 2003 documentation.
Note
Integrated Windows authentication is supported only on computers that are running a Windows operating system and Internet Explorer. Integrated Windows authentication may work with other Web browsers if they've been configured to pass the user's sign-in credentials to the server that's requesting authentication.
For more information about how to configure Integrated Windows authentication on an Outlook Web App virtual directory, see Configure Integrated Windows Authentication.
© 2010 Microsoft Corporation. All rights reserved.