Authentication Mechanisms for HTTP
The front-end server handles authentication in two ways: either the front-end server authenticates the user itself (either using Basic or forms-based authentication), or it forwards the request anonymously to the back-end server. Either way, the back-end server also performs authentication.
Note
Anonymous authentication on the front-end server is required when it is located in a perimeter network and cannot use Remote Procedure Calls. This is not a recommended scenario, as user access cannot be blocked by the front-end server. For more information about pass-through authentication, see "Pass-Through Authentication" later in this topic.
Important
It is strongly recommended that you use dual authentication, in which you configure both front-end and back-end servers to authenticate users. For more information, see "Dual Authentication" later in this topic.
Dual Authentication
By default, dual authentication is used with front-end and back-end servers. In dual authentication, both front-end and back-end servers are configured to authenticate users. You should configure front-end servers to perform authentication whenever possible. If you cannot enable authentication on the front-end server, implicit logon does not work, and you cannot load-balance public folder requests. You can use explicit logon to gain access, regardless of how authentication is configured.
Note
Exchange relies on IIS to authenticate HTTP requests. IIS uses RPCs to directory servers to do authentication. If RPCs are not allowed between the front-end server and the directory server, you must use pass-through authentication. For more information about how to enable pass-through authentication and the risks of doing so, see "Pass-Through Authentication" later in this topic.
Pass-Through Authentication
In pass-through authentication, the front-end server is configured with anonymous authentication, so it does not ask the user for an authorization header. The front-end server forwards the user's request to the back-end server, which asks the user for authentication. The back-end server's request for authentication and the user's response are routed unchanged through the front-end server.
Note
When you use pass-through authentication, anonymous HTTP requests go directly to the back-end server where they are authenticated. You should use pass-through authentication only if absolutely necessary. The recommended strategy is to place an advance firewall in the perimeter network and the front-end server behind the internal firewall – so it has full RPC access to the internal network. If you do want to place the front-end server in the perimeter network, it may be more secure to allow RPCs than to allow anonymous requests to reach back-end servers, because pass-through authentication allows requests from any source, valid or invalid, to be passed to your back-end servers. For more information, see Scenarios for Deploying a Front-End and Back-End Topology.
When pass-through authentication is used, the front-end server cannot load-balance public folder requests, because it does not have the authentication token on which to perform a hashing algorithm. Additionally, implicit logon will not work. Users must enter the full URL including their user name to log on.
Authentication Methods
There are several authentication methods for your front-end and back-end server architecture depending on the version of Exchange you are using. Additionally, authentication between the client and front-end server has different options, in contrast to the authentication used between the front-end and back-end servers. The following sections outline the two authentication methods.
Client to Front-end Server Authentication
Note
Front-end servers do not support integrated Windows authentication (which includes both NTLM and Kerberos authentication) or HTTP 1.1 Digest authentication.
Basic Authentication
Basic authentication is a simple authentication mechanism defined by the HTTP specification that lightly encodes the user's user name and password before sending it to the server. To achieve real password security in a front-end and back-end topology, you should use SSL encryption between the client and the front-end server.
Note
Basic authentication is supported by Exchange 2000 Server and Exchange Server 2003.
Basic authentication does not support single sign on. Single sign on is when a user logs on to a computer that is running Windows, the user authenticates against a domain, and then the user can access all resources and applications in the domain without re-entering their credentials. Microsoft Internet Explorer versions 4.0 and later allow single sign on for Web applications, including Outlook Web Access, if the server being accessed has Integrated Windows authentication enabled. Because front-end servers do not support Integrated Windows authentication, when users access HTTP applications, the front-end server always prompts them for authentication and they must re-enter their credentials, even if they already used Windows to log on. Users only have to enter credentials once per browser session however, because their credentials are cached in the browser process.
Important
When using a kiosk, be aware that caching credentials can pose a security risk if you cannot 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 the use of Outlook Web Access on a kiosk, ensure that you can close the browser between sessions and end browser processes. Otherwise, consider using a third-party product that incorporates two-factor authentication, in which the user must present a physical token with a password to use Outlook Web Access on the kiosk.
Forms-Based Authentication
Note
Forms-based authentication is supported only by Exchange Server 2003. However, you can use an Exchange2003 Server front-end with an Exchange2000 Server back-end and benefit from forms-based authentication.
Forms-based authentication uses a cookie to identify the user when the user has done the initial logon. Tracking this use of this cookie allows Exchange to time out inactive sessions. However, the initial user's name and password is still transmitted in clear text, similar to basic authentication. This is why SSL encryption must be used with forms-based authentication. For information about how to configure forms-based authentication, see the section titled "Configuring Forms-Based Authentication for Exchange Server 2003" in Configuring the Front-End Server to Assume a Default Domain.
Front-End to Back-End Authentication
The front-end server must send user credentials to the back-end server along with the Web requests so the back-end server can allow access to the data.
Integrated Authentication
Exchange 2003 front-end servers will use Kerberos authentication to protect user credentials between the front-end and back-end servers. If Kerberos authentication fails, a warning event will be logged and the front-end will try NTLM instead. If NTLM fails, an error will be logged and basic authentication will be used.
To allow the front-end to use integrated authentication, the back-end virtual servers should be configured to allow integrated authentication (which they are by default).
Note
Both Exchange 2003 and Exchange 2000 back-end servers will support integrated authentication from an Exchange 2003 front-end server.
Basic Authentication
The front-end proxies the basic authentication credentials to the back-end servers. To secure this information, it is highly recommended that IPSec be used between the front-end and back-end servers.
Note
Basic authentication between the front-end and back-end servers is supported by both Exchange 2000 and Exchange 2003 front-end servers.
User Logon Information
When authenticating against a front-end server, by default, the user must enter his or her user name in the following format: domain\username. You can configure the front-end server to assume a default domain so that users do not need to remember their domain.
An additional option for authentication is to configure a user principal name (UPN) for users. Normally a user's UPN is set to be the same as their e-mail address. This enables users to enter their UPN/e-mail address as their user name. For more information, see Configuring Exchange Front-End Servers.