Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Topic Last Modified: 2011-04-28
Standard authentication methods can help secure Microsoft Exchange Server 2010 Client Access servers for Outlook Web App.
In Exchange 2010, Client Access servers support Integrated Windows authentication and HTTP 1.1 Digest authentication for Exchange 2010 virtual directories. Exchange 2010 virtual directories on a server that's running only the Client Access server role support only Basic and forms-based authentication.
Standard authentication methods include Basic authentication, Digest authentication, and Integrated Windows authentication.
Note: |
---|
By default, Exchange 2010 enables forms-based authentication. |
Contents
Integrated Windows Authentication
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 authentication enables 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 isn't secure unless you require Secure Sockets Layer (SSL) encryption.
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 2008 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 can'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 the kiosk. |
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.
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 2008 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. |