Understanding Outlook Web Access

Outlook Web Access has a lot of neat features and capabilities that are outside the scope of this book. I’m not going to teach you how to customize it, deploy it for mobile devices, and so on; see the product documentation or the many white papers and references at http://www.microsoft.com/exchange/ for that. Instead, I focus this chapter on the security aspects of deploying and using Outlook Web Access. These aspects begin with considering how to design an appropriate front- end/back-end (FE/BE) topology, as well as planning how you’ll expose your servers to the Internet.

Front-End and Back-End Servers

In Exchange 5.5, it was possible to set up connector-only servers that didn’t store any mailboxes locally. However, users who wanted to access their mailboxes still had to connect directly to their mailbox servers. This was fine for local area networks (LANs), but it was a tricky proposition for Internet users, because the generally accepted best practice is not to expose mailbox servers directly to the Internet.

Microsoft Exchange 2000 solved this problem by introducing the concept of two distinct server types. Back-end (BE) servers (also sometimes just called mailbox servers) store mailbox and public folder data, and they accept client connections for that data. Front-end (FE) servers don’t store any user data, but they do accept client requests for Internet Message Access Protocol (IMAP), Post Office Protocol (POP), or Hypertext Transfer Protocol (HTTP) services. These requests are proxied to the appropriate BE server, so that the client only has to connect to the FE server. This allows you to protect your mailbox data behind appropriate firewalls or gateways while still allowing authorized Internet users. In addition, FEs provide load balancing for mailbox access, and a large number of mailboxes can be served by a single clustered pair of BE servers because they’re just accepting proxied requests.

There are several different topologies for using FE and BE servers together. It’s important to note that even though I’m talking about single FE and BE servers, you can have any number of either (the generally recommended ratio is four mailbox servers for each FE). You can configure load balancing or load distribution between the FEs in various ways, most of which we won’t cover here.

• You can put the FE in a demilitarized zone (DMZ) and open the necessary ports to the BE through the perimeter firewall. This is conceptually simple, but it requires opening a relatively large number of ports between the DMZ and the BE because the FE has to be able to talk to domain controllers for authenticating users.

• You can put the FE in the DMZ and use IPsec to secure communications between the FE and BE. This doesn’t solve the problem of having to open so many ports, although it does give you better assurance that traffic between the FE and BE won’t be read or tampered with.

• You can put the FE on the internal network and use a reverse proxy, such as Internet Security and Acceleration (ISA) Server, to filter and forward requests. A conventional proxy server accepts requests from clients inside the firewall and sends them to the Internet. A reverse proxy does the opposite: it takes connections from the Internet and directs them to internal hosts. Many reverse proxies can accept Secure Sockets Layer (SSL) connections, inspect them for signs of malicious behavior, and proxy them to the FE over a single port. The FE can stay safely inside the perimeter network, where it can easily communicate with the BE and domain controllers or global catalogs. ISA, in particular, understands Outlook Web Access traffic (and Exchange traffic, for that matter) quite well. As a bonus, you might recall from Chapter 12, “E-Mail Encryption,” that ISA can be used to directly publish Exchange servers for use with MAPI clients, giving your users the choice between the heavy but functional full version of Microsoft Outlook or the lightweight but not quite as full-featured Outlook Web Access.

Outlook Web Access and the Single Server

Most Outlook Web Access documentation and discussion centers around the FE/BE model, with good reason: FE/BE architectures offer great reliability and scalability, but they require a bit more configuration and tweaking than the easier to implement single-server configuration. In addition, you have to use Exchange 2000 Enterprise Edition to make a server act as an FE. Many smaller companies find that they either don’t need the added capability of the FE/BE topology or don’t want to buy another Exchange license. That’s perfectly fine, but it means that the security concerns such sites face will be somewhat different from their larger counterparts.

First, having a single Outlook Web Access server implies that the server also stores mailbox data. That means that you must be much more careful with exposing that server to the Internet because it has your mailboxes on it! Very small sites often put Exchange on a global catalog or domain controller machine, meaning that the risk of and loss associated with a compromise are elevated. Second, some of the best protective measures, like using back-to- back firewalls with SSL bridging, aren’t easily available to you. If you put your single Outlook Web Access server into a DMZ, you’ll have to have a relatively large number of open ports to allow the Outlook Web Access and global catalog servers to communicate, a problem that can largely be avoided by making the FE do pass-through authentication (although this opens its own set of potential risks, as described later in the chapter).

None of this is intended to make you rush out and buy another server just so you can have an FE. However, FE/BE topologies do give you much more flexibility; you can do things like move mailboxes between BE servers or take down one node of a mailbox cluster without users noticing. For that reason alone they might make sense for your network.

Note

This chapter’s discussion of FE/BE topology is still pertinent if you’re not using Outlook Web Access. The same rules and restrictions for FE/BE configurations apply to IMAP, POP, SMTP, and NNTP, too.

Understanding Outlook Web Access Authentication

In earlier chapters, we discussed the protocols and subsystems that provide authentication services for Exchange 2000. IIS can use two different but complementary authentication methods, which we’ll get to in a minute. First, though, it’s important to understand the two different types of logon methods that FEs support, because the choice of logon method has some authentication-related consequences.

How Outlook Web Access Handles Logons

There are two separate ways for a user to specify to Outlook Web Access which mailbox he or she wants. The first, explicit logon, includes the mailbox name in the Uniform Resource Locator (URL); Outlook Web Access can take a URL of the form http://serverName/exchange/userName and immediately figure out which mailbox is being requested. With explicit logon, Outlook Web Access takes the specified username and combines it with the SMTP domain name associated with that user to make a user principal name (UPN). The resulting UPN can be used to determine which BE has the user’s mailbox, and a logon to that server is attempted. Because explicit logon requires you to include the username, it can be used to access other mailboxes to which you have access, and it works whether or not the FE is able to directly authenticate the user request. By contrast, implicit logon doesn’t include the username; instead, Outlook Web Access uses the user’s credentials (which are supplied as part of the authentication request) to look up the appropriate BE in the global catalog. For implicit logon to be useful, the FE that accepts the initial request must have a way to directly authenticate the user so that it can determine where that user’s mailbox is homed, so authentication must be enabled on the FE—IIS depends on having the remote procedure call (RPC) connection back to the directory server.

Choosing an Authentication Method

Whether you use implicit or explicit logon, there are two primary authentication systems in use with Outlook Web Access:

• Basic authentication is the standard authentication method for Outlook Web Access; it’s the same authentication system originally introduced with National Center for Supercomputing Applications (NCSA) Mosaic and NCSA httpd back in 1994. When you use basic authentication, you’ll see the familiar credentials dialog box (Figure 14-1) in your Web browser; once you’ve entered your credentials, the browser encodes the credentials using base-64 encoding, then sends them to the server. The server must then decode the credentials and attempt to authenticate them by passing them to the standard Windows logon mechanism. If the credentials are invalid, the server returns an error to the browser, which prompts for credentials again. Basic authentication is inherently insecure because the credentials are easily stolen—there’s no encryption, and minimal obfuscation, on the client/server channel. However, it’s ubiquitous; just about every Web browser supports basic authentication. If you’re going to enable it on your Outlook Web Access server, make sure that you require the use of SSL along with it.

  
  Figure 14-1: The basic authentication dialog box appears when you’re using basic authentication, when integrated authentication fails and the browser needs your credentials, or when you’ve set specific access control lists on the requested Web directory.

• Integrated authentication, which is only supported by Internet Explorer for Windows, is what IIS calls the standard Windows authentication mechanism (you might still see it called NTLM or Windows challenge/response authentication in some older documents). With integrated authentication, the browser first attempts to authenticate you by using your Windows logon credentials (by default, this only works for intranet sites, but you can specify additional sites for which your logon credentials should be used). The browser transmits them to the server using the same mechanism that the client would use to log on to a domain controller (for example, Microsoft Windows 2000 and newer clients will try Kerberos and fall back to NTLM if necessary; other clients, like Internet Explorer 4, will use NTLM). If this doesn’t work, you’ll be prompted for credentials. This is a great time-saver for end users who are logging on to resources in a trusted domain while using a domain user account. However, it falls short for people using browsers other than Windows Internet Explorer, or people who are using HTTP proxy servers. This last restriction is the most serious for Outlook Web Access users, because it means that integrated authentication won’t work between an Outlook Web Access client and an FE server.

Both integrated and basic authentication are enabled by default in Exchange 2000 Outlook Web Access; you can use the Exchange System Manager to control which authentication methods you want your server to allow. There’s a third potential choice: you can allow anonymous users to send requests to the FE. This has the potentially serious consequence of allowing anonymous requests to go straight to the BE, which in most cases is not what you want. Besides the obvious security implications of allowing unauthenticated, untrusted traffic to go straight to your mailbox server, there are some Exchange-specific consequences. First, because the FE cannot tell who you are, it has no way to perform load balancing for public folder requests—it can’t tell which server to send the request to. Implicit logon won’t work, either, because the FE has no way to look up the user account in Active Directory to find out which mailbox server hosts the requested mailbox.

Pass-Through Versus Dual Authentication

An FE server can handle an incoming authentication request in one of two ways: it can authenticate the user itself by talking to a global catalog server, or it can pass the request straight to the BE, which is called pass-through authentication. The BE always authenticates a user before giving out any mailbox data. That leads to a variety of interesting behaviors that you must understand.

First, because the BE always authenticates the user, you can end up with two authentication requests for each user request: one from the FE and one from the BE. This is called dual authentication. The FE receives credentials from the user, then passes them (as part of every HTTP request) to the BE. Dual authentication requires you to have basic authentication enabled on the FE. It’s much better to use dual authentication when possible, because it allows the FE to authenticate requests before they reach the BE. However, for the FE to be able to do the authentication, you’ll need to pay careful attention to the issues surrounding RPC traffic from the FE to your internal network—see the section “Securing Outlook Web Access with Firewalls” later in the chapter.