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 illustrated in Figure 12.2. This certificate ensures the identify of the server itself, and allows the traffic to be virtually uncrackable, particularly if strong 128-bit encryption is used.
Figure 12.2. Examining SSL encryption for OWA traffic.
The upshot of this discussion is that it is vital, and almost always necessary, to secure OWA-based traffic using digital SSL certificates. It is less and less common to run into OWA implementations that are not secured with SSL, and this chapter focuses on deploying and securing OWA sites that use SSL to encrypt the traffic.
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 subsequent section of this chapter.
If a digital certificate is already installed and configured on an OWA server, this section can be skipped, and the reader can proceed directly to the section on securing OWA with ISA Server titled "Securing Exchange Outlook Web Access with ISA Server 2004."
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 follows up by researching the company, calling the CompanyABC employees, and conducting interviews to determine the validity of the organization. Based on the information obtained from this process, the third-party CA then encrypts the certificate and sends it back to CompanyABC, which then installs it on its server.
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 maintained by the internal IT branch of an organization, are more cost effective. Expensive third-party certificates (which can run up to $1000 a year in some cases) can be eschewed in favor of internally generated certificates. This also gives an organization more flexibility in the creation and modification of certificates. Windows Server 2003 includes the option of installing an enterprise certificate authority on an internal server or set of servers, giving administrators more options for SSL communications. The biggest downside to an internal CA is that, by default, not all browsers have the required certificate patch that includes the internal CA as part of the default installation, and therefore receive the error illustrated in Figure 12.3 when accessing a site secured by this certificate.
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 members, which can make this easier for an organization to deploy, but can still limit the deployment of a seamless solution. It is this limitation that sometimes stops organizations from installing their own CAs.
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 emailed or otherwise transmitted to the certificate authority via its own individual process. Each CA has a different procedure, and the exact steps need to follow the individual CA's process. After an organization's identity has been proven by the CA, it sends back the server certificate, typically in the form of a file, or as part of a the body of an email message.
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 ramifications, and each one is useful in different situations. The following is a list of the types of CAs available for installation:
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 viewed by clicking on the View Certificate button of the Directory Services tab under the Virtual Server properties.
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 especially necessary given the fact that most users simply connect to the OWA server from their browser by typing in the name of the server, such as mail.companyabc.com, which defaults to the unencrypted http:// prefix, rather than the encrypted https:// prefix. To solve this problem, SSL encryption must be forced from the OWA server via the following procedure:
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 methods. After the site is secured in this fashion, the ISA specific mail publishing rules can be applied.
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 user enters.
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 replaced by a custom ASP web page that redirects the requestor to the SSL website and the Exchange virtual directory on the server. The code of the ASP file can be input in Notepad and should be exactly as follows (do not replace any of the variables with real server names):
<% 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 constitute best practice OWA design. Consequently, Table 12.1 is provided to give administrators a quick glance at best practice OWA virtual server and virtual directory settings. This table is meant to be used as a general guideline for organizations seeking a laundry list of standard 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 packs should be to double-check these settings and validate functionality.