Authentication
A traditional front-end server/back-end server deployment handles user authentication in one of two ways:
- Pass-through authentication—The front-end server simply forwards the request to the back-end server, which performs the authentication.
- Dual authentication—The front-end server authenticates the initial user request, then forwards the request to the appropriate back-end server, which authenticates the request again.
Because the front-end server needs to determine the user's identity to forward the request to the appropriate back-end server, pass-through authentication requires an explicit logon. I don't recommend pass-through authentication for OWA access. Pass-through authentication lets anonymous HTTP requests go directly to the back-end server, thus exposing your server to rogue HTTP requests and potential Denial of Service (DoS) attacks. Pass-through authentication is also less desirable than dual authentication because most OWA users prefer to type the simplest possible URL. Figure 3 shows an explicit logon with pass-through authentication.
Dual authentication is the better approach because it allows implicit logons and their simpler URLs. Although dual authentication requires both front-end and back-end servers to perform authentication, as Figure 4 shows, users need to enter their credentials only once. After the front-end server authenticates the user's credentials, the server caches them within the client browser process. Front-end/back-end server implementations use dual authentication almost exclusively. One exception is when the front-end server can't use a remote procedure call (RPC) to communicate with a DC; this scenario might occur if a firewall separates the front-end server from the DC. In that case, pass-through authentication is necessary.
Front-end servers support only HTTP Basic authentication, which has several drawbacks. Because Basic authentication doesn't encrypt a user's credentials, I recommend that you always use Secure Sockets Layer (SSL) connections between OWA clients and front-end servers. Another drawback of HTTP Basic authentication is that it doesn't support single sign-on (SSO), which relies on Integrated Windows authentication (i.e., either NT LAN Manager—NTLM—or Kerberos authentication). Finally, with Basic authentication, users must always enter their credentials when they connect to a front-end server—even if they're already logged on to the Windows domain.
Pseudo Front-End Servers
Companies that use OWA would ideally like to be able to combine normalized namespaces and SSO. With such a combination, users could enter a simple, standard URL that would let the front-end server direct the browser session to the appropriate back-end server, and users who are logged on to the domain wouldn't need to reauthenticate. You can implement just such a combination by configuring what I call a pseudo front-end server.
A pseudo front-end server takes advantage of an Exchange server's redirection capability. A connection to a back-end Exchange server, even if the server doesn't host the desired user mailbox, results in the back-end server automatically sending a redirection to the client. The redirection includes a new URL that specifies the correct back-end server to which the client should connect. The client can then establish a direct connection to that back-end server. The server that the client originally contacted plays no further role in the communications stream between the client and the back-end server. Because a pseudo front-end server approach connects directly to a back-end server, you can use Integrated Windows authentication, which in turn supports SSO.
As Figure 5 shows, users can reference the pseudo front-end server (which is really just another back-end server) by typing a normalized URL of the form http://webmail.bigcorp.com/. You can use a pseudo front-end server in several ways. One way is to implement a pseudo front-end server solely to accept initial connections and redirect the client to the appropriate back-end server. In this case, the pseudo front-end server hosts no user mailboxes, so the server has little actual work to do. Another way is to use your pseudo front-end server to host mailboxes and perform redirections as additional workload. A third approach is to have all your back-end servers act as pseudo front-end servers and to use a load-balancing solution to share the workload across them.
Which Approach?
By understanding how OWA clients interact with Exchange front-end and back-end servers, you can choose the best approach for your environment. Pseudo front-end servers make sense when you want to use a normalized OWA namespace and Integrated Windows authentication or when you want to reduce overhead associated with multiple authentications. Traditional front-end servers still have their place, however—for example, they simplify publishing OWA services to the Web.