By itself, ISA Server 2004 supports a wide variety of client access mechanisms and contains a rich feature set from the server side alone. Through the use of software-less client access such as with the SecureNAT client and the Web Proxy client, ISA can secure network traffic and provide for caching and reverse proxy capabilities right out of the box.
In addition to these capabilities, ISA also supports the deployment of the full ISA Firewall Client, which provides unprecedented control over a firewall environment, allowing for per-
Part III: Securing Servers and Services with ISA Server 2004
IN THIS PART
Chapter 12. Securing Outlook Web Access (OWA) Traffic
IN THIS CHAPTER
One of the most common reasons for deploying ISA Server 2004 is for securing Outlook Web Access (OWA) sites from access from the Internet. ISA Server 2004 contains unprecedented capabilities to secure and protect an OWA server with its reverse proxy capabilities, forms-based authentication support, and end-to-end SSL encryption capabilities.
This chapter focuses on the best practice approaches to securing Outlook Web Access sites with ISA Server 2004. Specific step-by-step examples of setting up OWA with SSL encryption and forms-based authentication are presented. The examples in this chapter focus on a deployment scenario with ISA as an edge firewall.
The common scenario of ISA as a unihomed reverse proxy system in the DMZ of an existing firewall, used to secure OWA and other services, is covered in Chapter 7, "Deploying ISA Server as a Reverse Proxy into an Existing Firewall DMZ." That said, many of the
Enabling Secure Sockets Layer (SSL) Support for Exchange Outlook Web Access
The first and most common item that is secured with ISA Server 2004 is Exchange Outlook Web Access (OWA). OWA is a web-based email access method that displays a Microsoft Exchange mailbox, calendar, contacts, public folders, and the like in a web-based interface, such as the one shown in Figure 12.1.
Figure 12.1. Examining Outlook Web Access.
OWA was available as an option in Exchange 5.5, and became a standard component in Exchange 2000. The latest iteration of the product, available in Exchange Server 2003, provides for a rich, functional, mailbox-access mechanism, with many of the same features as the full-function Outlook client.
Traffic to and from an OWA server uses the web-based Hypertext Transfer Protocol (HTTP) to communicate with both client and server. The upside to using this protocol is that the OWA server can be accessed from any client on the Internet that supports the HTTP protocol.
The downside to OWA access with the HTTP protocol is that the traffic is sent in clear text, easily readable to any third party that intercepts the traffic sent across untrustworthy networks.
Fortunately, the HTTP protocol can be encrypted with a technology known as Secure Sockets Layer (SSL), which scrambles the packets sent between client and server by using a set of keys tied to an SSL certificate installed on the OWA server, such as what is
Figure 12.2. Examining SSL encryption for OWA traffic.
The upshot of this discussion is that it is
Installing a digital certificate on the Exchange OWA server, and later on ISA itself, involves a two-step process. In the first step, the certificate request must be generated from the OWA server and sent to a certificate authority. Secondly, the certificate authority must then verify the identify of the site and send a certificate back to the organization to be installed on the OWA server. The key to this process is to either use a third-party certificate authority such as Verisign or Thawte to provide the certificates, or to install and configure an internal enterprise certificate authority. Each of these processes is described in more detail in the
If a digital certificate is already installed and configured on an OWA server, this section can be
Understanding the Need for Third-Party CAs
By and large, the most common approach to securing an OWA server with SSL is to buy a certificate from a third-party certificate authority such as Verisign, Thawte, or one of many other enterprise certificate authorities. These companies exist as a trusted third-party vendor of digital identity. Their job is to validate that their customers are really who they say they are, and to generate the digital certificates that validate this for digital communications that require encryption, such as SSL.
For example, if CompanyABC wishes to create a certificate to install on its OWA server, it sends the certificate request to the third-party certificate authority (CA), who then
Because the third-party CA is registered on nearly all the web browsers (the most common ones always are), the client automatically trusts the CA and, subsequently, trusts the certificate generated by CompanyABC. It is because of this seamless integration with the majority of the world's browsers that third-party enterprise CAs are commonly utilized.
Internal certificate authorities, built and
Figure 12.3. Viewing a common SSL certificate error.
The only way to avoid this type of error message from appearing is to add the internal CA to the client's list of trusted root authorities, which can be a difficult prospect if OWA access is to be made available to browsers around the world. An enterprise certificate authority is automatically trusted by domain
Either third-party CA certificate generation or internal CA generation is required for SSL support on OWA. These deployment options are illustrated in the subsequent sections of this chapter.
Installing a Third-Party CA on an OWA Server
If a third-party certificate authority will be used to enable SSL on an OWA server, then a certificate request must first be generated directly from the OWA Server. After this request has been generated, it can be sent off to the third-party CA, who then verifies the identify of the organization and sends it back, where it can be installed on the server.
If an internal CA will be utilized, this section and its procedures can be skipped, and readers can proceed directly to the subsequent section, "Using an Internal Certificate Authority for OWA Certificates."
Although it is not a direct part of ISA Server, having an SSL-protected OWA server is the first step in protecting traffic to the OWA server, and is therefore illustrated in this chapter. It is possible to secure an OWA server without using SSL, through basic HTTP securing techniques, but it is highly recommended to use SSL where possible.
To generate an SSL certificate request for use with a third-party CA, perform the following steps:
After the certificate request has been generated, the text file, which will look similar to the one shown in Figure 12.5, can then be
Figure 12.5. Viewing a certificate request file.
The certificate then needs to be installed on the server itself. If it was sent in the form of a .cer file, it can be imported via the process described in the following steps. If it was included in the body of an email, the certificate itself needs to be cut and pasted into a text editor such as Notepad and saved as a .cer file. After the .cer file has been obtained, it can be installed on the OWA server through the following process:
At this point in the process, SSL communication to the OWA server can be allowed, but forcing SSL encryption requires more configuration, which is outlined in the later section titled "Forcing SSL Encryption for OWA Traffic."
Using an Internal Certificate Authority for OWA Certificates
If a third-party certificate authority is not utilized, an internal CA can be set up instead. There are several different CA options, including several third-party products, and it may be advantageous to take advantage of an existing internal CA. If none is available, however, one can be installed on an internal (non-ISA) Windows Server 2003 system in an organization.
Installing an Internal Certificate Authority
On a domain member (not the ISA Server) server or, more commonly, on a domain controller, the Certificate Authority component of Windows Server 2003 can be installed using the following procedure:
This procedure outlines the process on a Windows Server 2003 system. It is possible to install and configure a CA on a Windows 2000 system, through a slightly different procedure.
From the subsequent dialog box, shown in Figure 12.7, select what type of certificate authority is to be set up. Each choice of CA type has different
Figure 12.7. Selecting a CA type to install.
After choosing the type of CA required, continue the CA installation process by performing the following steps:
Installing an Internal Certificate on the OWA Server
After the Internal CA is in place, the OWA server can automatically use it for generation of certificates. To use an internal CA to generate and install a certificate on an OWA server, use the following technique:
The following procedure requires the ISA Server to be a domain member of the forest where the enterprise certificate authority is installed. If the ISA server is not a domain member, such as in the scenarios where ISA is a stand-alone server in the DMZ of an existing firewall, the enterprise CA cannot be accessed directly. Instead, the certificate must be installed either through use of a third-party CA or from the internal CA via web auto-enrollment. The procedure for installing an enterprise CA certificate on a stand-alone ISA Server via web auto-enrollment is covered in Chapter 7.
After installation, the certificate can be
After SSL is placed on a server, SSL encryption is made available on the OWA server. If the Enterprise Certificate Authority was installed in an Active Directory domain, then all the domain members will include the internal CA as a trusted root authority and connect to OWA via SSL with no errors. External or non-domain members, however, need to install the Enterprise CA into their local trusted root authorities to avoid the error message described in the previous section.
Forcing SSL Encryption for OWA Traffic
After either a third-party or a local internal certificate has been installed on an OWA server, it is typical to then set up the OWA server to force SSL traffic, rather than allow that traffic to use the unencrypted HTTP protocol. This is
Although it may seem like it is better to force SSL on the entire site, it is not actually required, and can also interfere with some of the functionality that may be needed, such as automatic redirection of users, covered in the next section of this chapter. The Exchange and Public virtual directories are the only default directories that should have their information encrypted.
Customizing and Securing an OWA Website from Internal Access
Before Outlook Web Access can be secured with ISA, it should pass through a series of internal securing procedures. This helps to mitigate the risk of internal attack against the OWA server, and prepares it for being further secured with ISA Server. The following section deals with best practice methods to optimize and secure the OWA site with standard Windows and Exchange
Redirecting Clients to the Exchange Virtual Directory
By default, any clients that access an OWA implementation by simply typing in the name of the server, such as mail.companyabc.com, do not gain access to OWA, as the full patch to the Exchange virtual directory (for example, http://mail.companyabc.com/exchange) must be entered. For external access through ISA, methods to automate this process are described later, but for internal access (without using ISA), a simple trick automates this procedure. To set up the automatic redirection to the Exchange virtual directory, perform the following steps on the OWA server:
With the automatic redirect in place, the OWA server is configured to automatically add the /exchange to the URL that the
Creating a Custom SSL Error to Redirect HTTP Traffic to SSL
One of the downsides to forcing SSL encryption on the OWA server is that the users receive a 403.4 error message similar to the one shown in Figure 12.12 when they try to connect to the OWA server using the standard http protocol.
Figure 12.12. Examining the 403.4 error message.
Although a handful of users would be able to recover from this error message and put the https:// as the prefix to the URL, a large number of them would probably not, which could make the OWA login process less than transparent and frustrating to many. A simple fix to this problem is to generate a custom error message to replace the 403.4 message with one that will automatically redirect the users to the https:// OWA namespace.
The 403.4 error message must be
<% If Request.ServerVariables("SERVER_PORT")=80 Then Dim strSecureURL strSecureURL = "https://" strSecureURL = strSecureURL & Request.ServerVariables("SERVER_NAME") strSecureURL = strSecureURL & "/exchange" Response.Redirect strSecureURL End If %>
The high-level process to create this message is as follows:
After the file is created, the virtual directory must be changed to allow anonymous connections and to use the proper application pool. If this is not done, users will not be properly redirected. Perform the following steps to set this up:
The last step is to actually change the 403.4 error message to use the custom ASP page. To do this, follow these steps:
At this point, the Exchange Outlook Web Access server is now configured to automatically redirect all users to SSL encrypted traffic, the first step to securing the OWA server for access from the Internet. In addition, the server is positioned to have ISA Server 2004 secure the access to the IIS Virtual Server, through ISA's mail publishing rules.
For more information on using this technique to redirect to SSL connections, reference MS KB article #555126 at the following URL:
Summarizing OWA Virtual Server Settings
It is sometimes difficult to keep track of the particular SSL and authentication settings that
Table 12.1. OWA Virtual Server Settings
Table 12.1 lists a full spectrum of potential virtual directories that an OWA server may use. Depending on what is installed and/or enabled, they may or may not be present on a particular OWA virtual server. The subsequent chapter of this book, Chapter 13, "Securing Messaging Traffic," has detailed information on setting up some of these features, such as OMA, RPC-HTTP, and ActiveSync.
Service packs and hotfixes can have the effect of erasing custom changes made in IIS Manager, including SSL and Authentication settings on virtual directories. One of the first things that should be done after applying patches or service