Understanding Outlook Web Access


Outlook Web Access has many 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 in 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. To address this limitation, Microsoft Outlook Web Access 5.5 could be installed on a separate IIS server, and many customers did just that, but those servers weren t considered part of the Exchange 5.5 organization and they had to be managed separately.

Microsoft Exchange 2000 Server 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 the Simple Mail Transfer Protocol (SMTP), 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 and public folder access and failover capacity for replicated public folders, and a large number of mailboxes can be served by a single clustered pair of BE servers because they re just accepting proxied requests.

Microsoft Exchange Server 2003 largely continues the FE/BE topology model as it was in Exchange 2000 Server, with a few significant additions. First, Exchange Server 2003 Standard Edition servers can act as FEs; in Exchange 2000 Server, that functionality was restricted to the Enterprise Edition. Exchange Server 2003 FEs can offer virus scanning services through third-party scanners that use version 2.5 of the Anti-Virus Application Programming Interface (AVAPI), and the Exchange Server 2003 FE can act as a gateway for Outlook Mobile Access and Exchange ActiveSync traffic as well. It s finally possible to reply to or forward items in public folders when accessing Outlook Web Access through an FE. As an extra benefit, many operations that would normally take place on the BE can be offloaded to the FE; for example, when accessing Outlook Web Access through an FE, processing for spell-checking is offloaded to the FE.

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 CPUs for each equivalently powered FE CPU, although your actual requirements will vary depending on the number of concurrent users you have to support and their activity profiles). 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 perimeter network (also known as a demilitarized zone or 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 perimeter network and the BE because the FE has to be able to talk to domain controllers for authenticating users. Microsoft doesn t recommend this, and neither do I.

  • You can put the FE in the perimeter network 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. However, this doesn t really reduce the danger inherent in having a sensitive machine (and a domain member, no less) semi-exposed in the perimeter network.

  • You can put the FE in the perimeter network and use some other kind of virtual private network (VPN) solution to tunnel through to the internal network, but as with the previous suggestion, this isn t really a comprehensive solution.

  • 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 internal network, where it can easily communicate with the BE and domain controllers or global catalogs (GCs). 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, Secure E-Mail, 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.

start sidebar
Outlook Web Access and the Single Server

Most Outlook Web Access documentation and discussion centers on 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. 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 Exchange server hosting Outlook Web Access 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 GC or domain controller machine, meaning that the risk of and loss associated with a compromise are elevated (not to mention the increased complexity of disaster recovery). 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 perimeter network, you ll have to have a relatively large number of open ports to allow the Outlook Web Access and GC 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). For that reason, the best solution is probably to keep the single Exchange server inside the network perimeter and publish it with a reverse proxy like ISA Server.

None of this discussion 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, Outlook Mobile Access, Exchange ActiveSync, SMTP, and Network News Transfer Protocol (NNTP), too.

end sidebar
 

Understanding Outlook Web Access Authentication

In earlier chapters, we discussed the protocols and subsystems that provide authentication services for Exchange Server 2003. 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 left side of the user s e-mail address in the Uniform Resource Locator (URL); Outlook Web Access can take a URL of the form http://serverName/exchange/userLHS and do a directory lookup to get the corresponding account security identifier (SID), which can in turn be used to figure out which mailbox is being requested . Exchange Server 2003 Service Pack 1 and later allow users to log on using their SMTP address directly; the mechanism it uses to decide whether the user s provided credentials are a user principle name (UPN), an SMTP address, or some mutant variant thereof is too complicated to go into here. With explicit logon, Outlook Web Access takes the specified username and combines it with the SMTP domain name associated with the requested virtual server or directory. The combined SMTP address has to match an SMTP address that s contained in the proxyAddresses attribute of a mail-enabled user object. The required SMTP address match is not the Windows username and domain, nor necessarily the account s mail attribute, so long as it matches some value of the user object s proxyAddresses attribute.

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 takes the SID passed back to it by the IIS authentication subsystem, then uses it to look up the mail-enabled account that belongs to that SID. From there, it s simple to look up the appropriate BE in the GC. 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 reach authentication method for Outlook Web Access; it s the same authentication system originally introduced with the National Center for Supercomputing Applications (NCSA) Mosaic and NCSA http back in 1994. When you use basic authentication, you ll see the familiar credentials dialog box (see Figure 14-1) in your Web browser; once you ve entered your credentials, the browser encodes the credentials using base-64 encoding and sends them to the server. (It s worth noting that base-64 is not an encryption method; it s just a way to convert binary data to ASCII characters , so it offers no protection against eavesdroppers.) 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 by anyone who can sniff traffic between the client and server ”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 (not just enable) the use of SSL along with it to ensure logon traffic is encrypted. The bonus to this is that all e-mail traffic is encrypted, unlike most freemail systems, which only encrypt the logon traffic.


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

  • Integrated Windows authentication (IWA), which is supported by Microsoft Internet Explorer for Windows, Internet Explorer for the Mac, and later versions of Mozilla, 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 IWA, 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 using the HTTP Negotiate authentication mechanism; other clients, like Internet Explorer 4 and 5, 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 Internet Explorer, or people who are using HTTP proxy servers that cannot proxy NTLM authentication. This last restriction is the most serious for Outlook Web Access users, because it means that IWA won t work between an Outlook Web Access client and an FE server.

There are also a number of other authentication methods that you ll see when you configure Outlook Web Access authentication. So why did I say that there were only two? Here s a rundown of the other methods:

  • Digest authentication, which computes a one-way hash of the credentials and sends that over the wire. This method only works when the client and the server are both members of the same Active Directory domain. For that reason, this is not generally used with Outlook Web Access, because there s no guarantee that the client will be connecting from a machine that is a member of the domain.

  • Certificate mapping, in which users present digital certificates to be authenticated. I ll discuss this a bit later in the chapter.

  • .NET Passport authentication allows users to authenticate to an IIS server using their Passport account. Unfortunately, this doesn t do a bit of good in helping the user authenticate to the BE where the actual mailbox lives, so this isn t useful for Outlook Web Access.

Both IWA and basic authentication are enabled by default in Exchange 2003 Outlook Web Access; you can use 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, because the FE cannot tell who you are. First, the FE has no way to perform load balancing for public folder requests because 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 GC 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, form-based, or SSL client certificate 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.

Form-Based Authentication

In Exchange 5.5, users had to log on by typing their mail alias into a Web page form and then typing their credentials into the standard browser logon dialog box, after which they were authenticated using basic or NTLM authentication. Users frequently complained about this process, because there was no way for them to store their credentials. In Exchange 2000 Server, Microsoft added support for IWA, eliminating the logon form. However, some sites wanted to add it back (a topic I covered at length in the Exchange 2000 Server edition of this book). Why? Well, think back to the way that HTTP works: the browser automatically sends credentials to the server when requested, whether or not the original user is in control. Think of a typical kiosk: User 1 logs on and checks mail, closes Outlook Web Access, and walks away. If User 2 comes to the kiosk and logs on, User 1 s Outlook Web Access session might still be available if any Internet Explorer windows or objects are still open. This leads to attacks where credentials are reused; several third parties (including MessageWare) attempt to mitigate this by providing solutions that close the session after a set period, but these products aren t supported by Microsoft.

The only real way to protect against this attack is to keep the browser from caching the credentials, which is exactly what the form-based authentication (FBA) feature in Exchange Server 2003 does. When Exchange Server 2003 is installed, its setup program creates two anonymously accessible resources: a logon page (implemented as an ASP) and an Internet Server Application Programming Interface (ISAPI) extension (call it #1). Another ISAPI extension (#2) is also installed to catch OnAccessDenied events for the Outlook Web Access virtual directories, redirecting the client to the anonymously served logon page.

With FBA, the authentication process works like this:

  1. The user requests an Outlook Web Access resource for the first time.

  2. IIS can t honor the request because the user hasn t provided any credentials, so it produces an OnAccessDenied error, which is caught by the #2 ISAPI filter.

  3. The ISAPI filter redirects the request to the logon page, including the originally requested URL as a query string so that after a successful authentication the client can be redirected again.

  4. The browser accepts the redirect to the logon page and displays the page; the user types in credentials and clicks Logon. This causes the browser to perform an HTTP POST of the credentials. The #1 ISAPI extension receives this request, passes on the authentication request, and builds a cookie that contains the encrypted credentials. When this is done, the #1 extension issues a Set-Cookie HTTP header so that the client receives the cookie, along with a redirection to the original URL the user requested in step 1.

  5. The browser automatically includes the session cookie it got in step 4; ISAPI extension #1 will receive the cookie, decrypt it, and add the user s authentication data to the request header.

  6. IIS processes the request, which now contains authentication data, and hands it off to Outlook Web Access for action.

Because of the way cookies work, once a browser receives a cookie for a particular domain, it will automatically send that cookie along to the server, which can use it to determine whether the client should be granted access. Outlook Web Access extends this fundamental idea by allowing administrators to set a timeout after which the cookie is invalid, and this timeout can be set differently for trusted and public computers. As long as users are honest about what kind of machine they re logging on from, this addresses credential reuse attacks by letting administrators set a short timeout value for logons from public Internet terminals, allowing a longer timeout for machines that the end user trusts, like a laptop or (hopefully well- maintained ) home PC. By default, the public timeout is 15 minutes, and the trusted system timeout is 24 hours. You can modify these values by adjusting the PublicClientTimeOut and TrustedClientTimeOut values beneath the HKLM/System/CurrentControlSet/Services/MsExchangeWeb/OWA registry key on the FE ”both values must be specified in minutes, and 24 hours (or 1440 minutes) is the maximum for either.

So, what s in the cookie? Outlook Web Access generates a session cookie, which browsers aren t allowed to write to disk. In addition, the Set-Cookie response includes the HTTPOnly directive, so browsers like Microsoft Internet Explorer 6 Service Pack 1 will not allow a script to obtain the cookie through document.cookie() JavaScript requests. The cookie contains a session identifier and an encrypted base-64 version of the user s credentials, along with other information. A periodically and randomly generated symmetric key generated by the server protects these credentials. Because the cookie contains the credentials, and because it s passed to the server with each client-side request, the server can use the credentials to reauthenticate the user when necessary. (The best part is that the client doesn t need the key, because all it does is parrot back the encrypted cookie; thus there s no way for a compromised client to steal the key!) The cookie doesn t contain a timeout value; the HTTP specification says that a cookie with no timeout value is to be treated as a session cookie and purged when the browser closes.

The server keeps two separate sets of these keys around: the current key and the two previous versions. This is necessary to allow the timeout system to work properly; without keeping multiple keys, a user who logged on right before the key was regenerated would almost immediately have to reauthenticate. The server regenerates its keys when half the timeout period has passed; because it keeps two previous versions around, the user might be able to log on for slightly longer than the defined timeout period. Because the cookie also contains a key sequence number, the server can tell when the client is using an expired key, so it can redirect the client to the logon page to obtain a fresh one.

Using Constrained Delegation and Kerberos

One new feature of Microsoft Windows Server 2003 that hasn t gotten a lot of attention is constrained delegation. With ordinary application server delegation, a user gives his or her credentials to the Web server, which then uses them to impersonate that user to an application somewhere on the network. Unfortunately, in this model there s nothing stopping a rogue (or poorly written) application from using those credentials to impersonate the user to a different service. Imagine a scenario in which a user logs on to use a purchasing system but ends up giving credentials to a program that modifies his or her direct-deposit payroll information and you get a good sense of the problem.

With constrained delegation, administrators can specify which specific services or servers a computer can request delegation to, choosing a specific service or computer account. The benefit is obvious when you consider the impact of using constrained delegation to restrict an FE s delegating ability to BE servers only. It s not even hard to set up, although it does require Windows Server 2003 on the FE (the BE can be running Windows 2000), and it requires that the user and FE server domains are at the Windows Server 2003 functional level. The server and the user account must both be in the same domain. As a side benefit, because constrained delegation depends on Kerberos, no cleartext credentials will be exchanged between FE and BE. Once Kerberos constrained delegation is enabled, it is used regardless of the authentication mechanism to the FE ”Basic, FBA or SSL client certificates ”because all it requires is a valid, authenticated token to use to delegate a request to another server.

Setting up constrained delegation for Outlook Web Access is a simple process. First, you might need to use the SETSPN utility (included in the Windows 2000 Resource Kit and as part of Windows Server 2003) to create service principal names (SPNs) for the http and HOST SPNs on your Exchange BEs. Next, you need to use the Active Directory Users And Computers snap-in to grant delegation authority to the FE. This is pretty simple:

  1. Launch Active Directory Users And Computers, then navigate to the Computers container (or wherever the FE is located).

  2. Open the Properties dialog box for the selected FE.

  3. Click the Delegation tab (see Figure 14-2).


    Figure 14-2: The Delegation tab of the computer Properties dialog box is where you can apply the delegation settings you want to use.

  4. Select the Trust This Computer For Delegation To Specified Services Only option.

  5. Select the Use Any Authentication Protocol option, because Windows Server 2003 allows you to translate other authentication protocols into Kerberos requests.

  6. Click Add and use the resulting Add Services dialog box to select the SPNs you created with SETSPN and assign them delegation permissions. You ll end up with two assigned services: HOST and http.

Authenticating with SSL Client Certificates

Another exciting IIS 6.0 feature is its improved ability to handle client authentication using X.509 certificates (actually, IIS 5.0 had this feature, too, but without constrained delegation it wasn t very useful). When this authentication method is in use, the client and server authenticate each other using their certificates through the normal SSL 3.0 handshake process; in traditional SSL-protected exchanges, the client can validate the server s identity, but not vice versa. Using certificate authentication provides Outlook Web Access users a single sign-on experience ” once the certificate is validated , no further sign-on is necessary.

For this process to work, clients obviously must have certificates; like Outlook Web Access Secure/Multipurpose Internet Mail Extensions (S/MIME), this is an application that fairly cries out for smart cards or tokens for user certificate storage. By configuring IIS, you can enable IIS to map a given certificate s distinguished name (DN) to an Active Directory user account, at which point IIS can authenticate the user normally. Microsoft Knowledge Base article 257586 describes how this authentication process works; of course, whether or not it actually works is completely dependent on IIS and Windows; it has nothing to do with Exchange.

The list of requirements for using client-side certificates is fairly daunting:

  • Every client needs a certificate that can be used for authentication. That, of course, means that you need a public-key infrastructure (PKI) for issuing, revoking, and managing them. Users have to have these certificates locally. If you want to use implicit mapping (in which the UPN on the certificate must match the UPN in Active Directory), the certificate doesn t have to be published in Active Directory. However, if you want to use explicit mapping (in which a particular account s altsecid attribute in Active Directory is updated to contain the subject of the linked certificate), the certificates have to be published to Active Directory. If you want to use a third-party PKI, good luck; as long as you can get it to work properly with IIS and Windows, you might be able to get it to work with Exchange.

  • Kerberos constrained delegation must be enabled from each FE to all BEs. Those FEs must be running Windows Server 2003.

  • All domain controllers involved (for example, those used by clients or Exchange servers) must be running Windows Server 2003, and the domain functional level must be raised to its maximum level. Users must be in the same forest as the FE server ”there s no support for cross-forest sign-on using this method because Kerberos constrained delegation cannot be used across forests (or across Kerberos realms, for that matter).

  • You must carefully configure authentication. HTTP authentication must be totally disabled on the Exchange virtual directories of the FE; that includes basic and anonymous authentication. In addition, HTTP authentication must be disabled for the /Exchweb/Bin directory (which will require you to turn off the system attendant service on the FE).

  • SSL must be properly configured. In particular, you must force SSL on the root of the Exchange virtual server and ensure that SSL connections work properly. You ll also have to require the use of client certificates for authentication.

  • IIS must be instructed to enable certificate mapping, as described in Knowledge Base article 272175. Microsoft has a good article available at http://www.microsoft.com/windows2000/techinfo/planning/security/mappingcerts.asp that describes the process of setting IIS up for this and configuring it to correctly authenticate users based on the certificates that they present.




Secure Messaging with Microsoft Exchange Server 2003
Secure Messaging with MicrosoftВ® Exchange Server 2003 (Pro-Other)
ISBN: 0735619905
EAN: 2147483647
Year: 2004
Pages: 189

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net