Many administrators refuse to run Outlook Web Access (OWA) because of the implied security risks of mixing e-mail with Web server technology. In the past when I’ve been in charge of IT departments for various organizations, I too refused to deploy OWA because of security concerns. Like so many others, I chose to simply link mobile users to my Exchange servers via POP3 and SMTP. While I still have at least a few reservations about using OWA, there has been a lot of progress made recently in regards to OWA security. In this Daily Drill Down, I’ll share with you some techniques that you can use to make OWA as safe as possible.

Secure Exchange first

This article assumes that you’ve already got a basic knowledge of Exchange security. For example, it’s difficult to really secure OWA without running the IIS Lockdown tool and the Microsoft Baseline Security Advisor. I cover these tools and more in the Daily Drill Down “Secure your Exchange 2000 servers with these strategies”.

Use the front-end/back-end server configuration
For the absolute best possible OWA security, Microsoft recommends that you use a front-end/back-end server configuration. The front-end server is what the end users interact with, while the back-end servers contain all of the mailboxes, public folders, and other Exchange resources. The idea is that the back-end servers should be completely out of the reach of Internet users, since those servers do most of the work and contain all of the Exchange resources. The front-end server is nothing more than an OWA interface combined with some routing information.

In a front-end/back-end configuration, a user would connect to the front-end OWA server. The front-end server would accept the user request, validate the user’s credentials through the Active Directory, and then forward the request to a back-end Exchange server for the necessary processing. Although this particular configuration requires a lot of servers, there are some definite advantages to using this method.

First, the Exchange servers that contain the actual mailboxes are hidden from view. In fact, OWA users don’t even need to know the name of the Exchange Server containing their mailboxes. Another advantage is that you can apply lots of security to the back-end servers that you wouldn’t be able to apply to the front-end servers. Finally, the overhead associated with SSL can be offloaded to the front-end servers, and the front-end servers can even be load balanced. As you can see, the front-end/back-end configuration provides performance and security. In the sections below, I’ll show you how to go about implementing a front-end/back-end configuration.

The front-end security configuration
The first step in implementing an effective front-end/back-end OWA configuration is to determine your security needs on both the front end and on the back end. Once you’ve determined your security needs on both ends, you can begin connecting the front end to the back end.

The more services that are running on a server, the greater the chance that one of the services could contain a bug that could be exploited by a hacker or a virus to gain unauthorized access to the server. In an OWA environment, there are some services that you should disable on the front-end server that go beyond the ones you’d normally stop on an Exchange server. Here ‘s a list of some of the Exchange related services and the recommended startup mode.

  • The Microsoft Exchange IMAP4 should be disabled because the OWA front-end server won’t be configured to use IMAP4.
  • The Microsoft Exchange Information service should be disabled because the OWA front-end server won’t contain a mailbox store or a public folder store.
  • The Microsoft Exchange POP3 service should be disabled because the OWA server won’t be configured to use POP3. Likewise, the SMTP Service may also be disabled.
  • The Microsoft Search service should be disabled because there are no stores to search on an OWA front-end server.
  • The Microsoft Exchange Event service should be disabled, as should the Microsoft Exchange Site Replication Service, because these services are used only for backward compatibility purposes.
  • The Microsoft Exchange Management service should be disabled, since you won’t be doing any message tracking on the OWA front-end.
  • The Exchange MTA Service should be disabled unless you’re using X.400 connectors.
  • The System Attendant Service should be set to Manual. In a server that’s acting purely as an OWA front-end, the System Attendant is only started when you wish to make configuration changes to the server. The System Attendant should be stopped at all other times.
  • The Microsoft Exchange Routing Engine service should be set to an Automatic startup mode because Exchange routing is required between the front-end and the back-end.
  • The IPSec Policy Agent service should be set to Automatic because you’ll want to implement an IPSec filter on your OWA Server.
  • The RPC Locator service should be set to Automatic because it’s necessary for the system attendant to start, and necessary for communications with domain controllers.
  • The IIS Admin Service must be set to Automatic because it’s required by the Exchange Routing Engine Service.
  • Finally, the WWW Publishing Service must be set to Automatic because the clients use this service for communications with the OWA front-end server.

The back-end security configuration
Now that I’ve discussed the security settings for the front-end servers, lets take a look at the back-end servers. As with the front-end servers, you should minimize the number of services running on the back-end servers. Below, I’ve listed several services and the recommend startup mode. Keep in mind that these settings are in addition to those found in my Daily Drill Down on securing Exchange.

  • The IMAP4 Service should be disabled because the back-end servers don’t use IMAP4.
  • The Exchange Information Store should be set for an Automatic startup because the information store is necessary for mailboxes and public folders.
  • POP3 should be disabled unless the server is acting as a POP3 server.
  • The Microsoft Search service should be disabled because it’s not required for functionality.
  • The Microsoft Exchange Event Service and the Microsoft Exchange Site Replication Services should be disabled unless you need them for backward compatibility.
  • The Microsoft Exchange Management service should be set to Automatic because it allows for the tracking of messages.
  • The Windows Management Instrumentation Service should be set to Automatic because it’s required for Exchange Server management.
  • The Microsoft Exchange MTA Stacks should be disabled unless you’re using X.400 connectors.
  • The Microsoft Exchange System Attendant must be set to Automatic because it’s required by other Exchange services. Furthermore, the System Attendant service requires the Event Log, NTLM Security Support Provider, RPC, RPC Locator, Server, and Workstation services to be running.
  • The Microsoft Exchange Routing Engine must be running because it’s needed for routing messages between Exchange servers.
  • The IPSec policy agent must be set to Automatic because you’ll want to encrypt data flowing across the wire with IPSec.
  • The RPC Locator service must be set to Automatic because its necessary for communications with domain controllers and clients.
  • The IIS Admin Service must be set to Automatic because it’s required by the Exchange Routing Engine Service.
  • The NTLM Security Support Provider service must be set to Automatic because it’s required by the System attendant.
  • The SMTP Service must be set to Automatic because Exchange uses SMTP for message transport.
  • Finally, the WWW Publishing Service must be set to Automatic because it’s necessary for communications with OWA front-end servers.

Putting it all together
Now that you’ve secured the front-end and back-end servers, it’s time to join the front end to the back end. There are lots of different ways of accomplishing this, but the method that you use to join the front end to the back end is critical to a secure OWA environment. Unless you use the method that I’m about to show you, or use something similar, all of your hard work in securing the front-end and back-end servers will have been in vain.

The first thing that I recommend doing is to create three different OUs in your Active Directory. One should be for OWA front-end servers, another for OWA back-end servers, and yet another for SMTP front-end servers. The act of placing the different types of servers into different OUs doesn’t do anything for security by itself. What it does, however, is give you the ability to create some OU level group policies. For example, you’ll probably want to assign an entirely different group policy to your front-end servers than to your back-end servers. Having the servers in different OUs makes it easy to do so.

Next, it’s time to secure the communications between the users and the various servers. As you probably know, outside users access OWA servers through port 80 (HTTP) and port 443 (HTTPS). The OWA Server must then be able to communicate with your network’s domain controllers and your back-end Exchange servers. Traditionally, you would accomplish this by placing the front-end server into a DMZ and placing the back-end server behind a firewall. The disadvantage of using this method, however, is that it requires lots of ports to be open in the firewall.

A good alternative to opening a bunch of ports in your firewall is to implement ISA Server as an application layer firewall. By doing so, you can place both your OWA servers and your SMTP servers behind the ISA firewall. You can then use ISA Server’s publishing rules to get the ISA Server to proxy those services to the outside world. In essence, Internet users will be talking to an ISA Server, but will have the illusion that they are communicating directly with an OWA or an SMTP server.

You can see an example of how everything works by looking at Figure A. For the sake of illustration, the figure shows the role of the SMTP front-end server, although SMTP servers are slightly beyond the scope of this Daily Drill Down.

Figure A
You can obtain the best security by using a front-end/back-end OWA configuration.

As you can see in Figure A, requests come in from the Internet and are filtered by your firewall. The firewall should be set to block all inbound traffic except for the traffic flowing through ports 80 and 443. Once the inbound request passes through the firewall, it is sent to the ISA Server.

In case you’re wondering why the traffic flows through the ISA Server rather than going directly to the OWA front-end server, there are two reasons. First, the ISA Server has two NICs. One NIC is connected to the firewall and the other NIC is connected to your private network. This makes it impossible for inbound traffic to get to your private network without flowing through the ISA Server. More importantly though, you must publish the ISA Server’s IP address in your DNS Server, rather than the address of the OWA Server. Although technically both addresses would be in the DNS Server, the ISA Server would be associated with the FQDN normally used for your OWA Server. For example, if I were to use this configuration on my personal network, then the mail.brienposey.com FQDN would be mapped directly to an ISA Server rather than to an OWA server.

Once the inbound request makes it to the ISA Server, the ISA Server passes the request to the OWA front-end server. The OWA front-end server then contacts the global catalog server (one of your domain controllers) and authenticates the user. As a part of the authentication process, the OWA server also looks up on which Exchange server the user’s mailbox resides and resolves the server name to an IP address. Once the OWA Server knows the IP address of the back-end server, it establishes an HTTP connection to the back-end server, where the request is finally processed.

As if this arrangement weren’t complex enough, there is still more that must be done. So far you’ve done nothing to encrypt the traffic. Any time that you’re dealing with Web based users, you must assume that using NTLM authentication isn’t an option. (Remember that HTTP and HTTPS are the only protocols that are still enabled.) That leaves two authentication options: basic and anonymous. You don’t want to use anonymous authentication because it would give the entire world access to your server. This leaves you dependent on basic authentication.

Unfortunately, basic authentication involves transmitting all login credentials in clear text. Since you don’t want clear text passwords flowing across the wire, I recommend implementing SSL encryption (this is where port 443 comes in). To obtain the maximum level of security, you should implement SSL encryption between the end user and the ISA Server. You should then implement SSL encryption between the ISA Server and the OWA front-end server. As you do, keep in mind that the ISA Server uses a completely different HTTP or HTTPS session for communication between the ISA Server and the OWA front-end server than between the ISA Server and the Internet. Therefore, since you have two different HTTP connections at work, you should use two different SSL certificates for maximum security.

The last step is to secure communications between the OWA front-end server and the OWA back-end server. Communications between the two servers are still HTTP or HTTPS based, but since both servers exist within your private network, you can encrypt the data by using the IPSec protocol.

Safe and sound
By its very nature, OWA has some security weaknesses. However, by combining multiple servers in a front-end/back-end manner, you can secure OWA communications. Toss in a bit of ISA server for good measure, and you can use OWA with a clear conscience.