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 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.

NOTE

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."

NOTE

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:

1.	From the OWA Server (not the ISA Server) open IIS Manager (Start, All Programs, Administrative Tools, Internet Information Services [IIS] Manager).
2.	Under the console tree, expand SERVERNAME (local computer), Web Sites and right-click the OWA Virtual Server (typically named Default Web Site), and then click Properties.
3.	Select the Directory Security tab.
4.	Under Secure Communications, click the Server Certificate button.
5.	At the welcome page, click Next to continue.
6.	From the list of options displayed, select Create a New Certificate and click Next to continue.
7.	From the Delayed or Immediate Request dialog box, select Prepare the Request Now, But Send It Later and click Next.
8.	Type a descriptive name for the certificate, such as what is shown in Figure 12.4, leave the Bit Length at 1024, and click Next to continue. Figure 12.4. Generating an SSL certificate request for an OWA virtual server.
9.	Enter the name of the organization and what organizational unit will be associated with the certificate. These fields will be viewable by external users, and should accurately reflect the organizational structure of the requestor.
10.	Enter a common name for the OWA website in the form of the Fully Qualified Domain Name (FQDN). An example of this would be mail.companyabc.com. Click Next to continue. NOTE If the OWA site will be made accessible from the Internet, the common name of the site needs to be made accessible from the Internet via a DNS A record.
11.	Enter the appropriate information into the Geographical Information dialog box, such as State, City, and Country. Abbreviations are not allowed. Click Next to continue.
12.	Enter a filename for the certificate request, such as C:\owacert.txt, and click Next to continue.
13.	On the Request File Summary dialog box, review the summary page for accuracy and click Next to continue.
14.	Click Finish to end the Web Server Certificate Wizard.

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:

1.	From the OWA Server (not the ISA Server) open IIS Manager (Start, All Programs, Administrative Tools, Internet Information Services [IIS] Manager).
2.	Under the console tree, expand SERVERNAME (local computer), Web Sites, and right-click the OWA Virtual Server (typically named Default Web Site), and then click Properties.
3.	Select the Directory Security tab.
4.	Under Secure Communications, click the Server Certificate button.
5.	At the welcome page, click Next to continue.
6.	From the Pending Certificate Request dialog box, select Process the Pending Request and Install the Certificate and click Next to continue.
7.	Enter the pathname and filename where the .cer file was saved (the Browse button can be used to locate the file), and click Next to continue.
8.	Click Finish to finalize the certificate installation.

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:

NOTE

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.

1.	Click on Start, Control Panel, Add or Remove Programs.
2.	Click on Add/Remove Windows Components.
3.	Check the box labeled Certificate Services.
4.	At the warning box, shown in Figure 12.6, click Yes to acknowledge that the server name cannot be changed. Figure 12.6. Installing a local Certificate Authority.
5.	Click Next to continue.

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:

• Enterprise root CA An enterprise root CA is the highest level certificate authority for an organization. By default, all members of the forest where it is installed trust it, which can make it a convenient mechanism for securing OWA or other services within a domain environment. Unless an existing enterprise root CA is in place, this is the typical choice for a home-grown CA solution in an organization.

• Enterprise subordinate CA An enterprise subordinate CA is subordinate to an existing enterprise root CA, and must receive a certificate from that root CA to work properly. In certain large organizations, it may be useful to have a hierarchy of CAs, or the desire may exist to isolate the CA structure for OWA to a subordinate enterprise CA structure.

• Stand-alone root CA A stand-alone root CA is similar to an enterprise CA, in that it provides for its own unique identity and can be uniquely configured. It differs from an enterprise CA in that it is not automatically trusted by any forest clients in an organization.

• Stand-alone subordinate CA A stand-alone subordinate CA is similar to an enterprise subordinate CA, except that it is not directly tied or trusted by the forest structure, and must take its own certificate from a stand-alone root CA.

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:

1.	In this example, an enterprise certificate authority is chosen. Click Next to continue.
2.	Enter a common name for the certificate authority, such as what is shown in Figure 12.8. Click Next to continue. Figure 12.8. Entering a common name for the certificate authority.
3.	Enter locations for the certificate database and the database log (the defaults can normally be chosen) and click Next to continue.
4.	Click Yes when warned that the IIS Services will be restarted.
5.	Click Finish after the installation is complete.

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:

CAUTION

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.

1.	From the OWA Server (not the ISA Server) open IIS Manager (Start, All Programs, Administrative Tools, Internet Information Services [IIS] Manager).
2.	Under the console tree, expand SERVERNAME (local computer), Web Sites, and right-click the OWA Virtual Server (typically named Default Web Site), and then click Properties.
3.	Select the Directory Security tab.
4.	Under Secure Communications, click the Server Certificate button.
5.	At the welcome page, click Next to continue.
6.	Select Create a New Certificate and click Next to continue.
7.	From the Delayed or Immediate Request dialog box, select Send the Request Immediately to an Online Certification Authority and click Next to continue.
8.	Enter a name for the certificate, such as CompanyABC OWA Certificate, leave the bit length at 1024, and click Next to continue.
9.	Enter the Organization and Organizational Unit name, keeping in mind that they should accurately reflect the real name of the requestor. Click Next to continue.
10.	Enter the Fully Qualified Domain Name (FQDN) of the OWA server, such as mail.companyabc.com.
11.	In the Geographical Information dialog box, enter an un-abbreviated State, City, and Country and click Next to continue.
12.	Specific the SSL port (443 is the default) that the server is to use and click Next to continue.
13.	Under the Choose a Certification Authority dialog box, shown in Figure 12.9, select the CA that was set up in the previous steps and click Next to continue. Figure 12.9. Installing a local CA certificate on an OWA server.
14.	Review the request in the Certificate Request Submission dialog box and click Next to continue.
15.	Click Finish when complete.

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:

1.	On the OWA Server (not the ISA Server) open IIS Manager (Start, All Programs, Administrative Tools, Internet Information Services [IIS] Manager).
2.	Navigate to Internet Information Services, Websites, OWA Web Site (usually named Default Web Site).
3.	Right-click on the Exchange virtual directory (under the OWA Virtual Server) and choose Properties.
4.	Choose the Directory Services tab.
5.	Under Secure Communications, click the Edit button.
6.	From the Secure communications dialog box, shown in Figure 12.10, check the boxes for Require Secure Channel (SSL) and Require 128-bit Encryption. Figure 12.10. Forcing SSL encryption on the Exchange virtual directory.
7.	Click OK, OK.
8.	Repeat the process for the Public virtual directory.

NOTE

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:

1.	On the OWA Server, open IIS Manager (Start, All Programs, Administrative Tools, Internet Information Services [IIS] Manager).
2.	Navigate to SERVERNAME, Web Sites.
3.	Right-click on the OWA Virtual Server (usually Default Web Site) and choose Properties.
4.	Select the Home Directory tab.
5.	Change the setting under the heading The Content for This Resource Should Come From to A Redirection to a URL, and enter /exchange into the Redirect To field, as shown in Figure 12.11. Figure 12.11. Setting the OWA Virtual Server to automatically use the exchange virtual directory.
6.	Check the check box labeled A Directory Below URL Entered.
7.	Click OK.
8.	When prompted about inheritance overrides, click OK.
9.	Restart the IIS Services by right-clicking on the name of the server in IIS Manager and choose All Tasks, Restart IIS.
10.	Click OK to complete the restart of IIS.

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:

1.	Create a directory in C:\Inetpub\wwwroot called owaasp (where C:\is the OS drive).
2.	In Notepad, create a file named owahttps.asp, with the code listed in the preceding passages, and place it in the C:\Inetpub\wwwroot\owaasp directory.
3.	Open IIS Manager (Start, All Programs, Administrative Tools, Internet Information Services [IIS] Manager).
4.	Expand SERVERNAME, Web Sites.
5.	Right-click the OWA Virtual Server (usually called Default Web Site) and choose New, Virtual Directory.
6.	Click Next at the wizard welcome dialog box.
7.	Under the Virtual Directory Alias dialog box, enter OWA_Redirect as the Alias name, as shown in Figure 12.13. Figure 12.13. Creating a virtual directory for OWA HTTP Redirection to SSL.
8.	Enter C:\Inetpub\wwwroot\owaasp as the directory path and click Next to continue.
9.	Under the Virtual Directory Access Permissions dialog box, choose only Read and Run Scripts from the permissions displayed (the defaults) and click Next to continue.
10.	Click Finish.

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:

1.	From IIS Manager, expand the OWA Web Site, right-click on the newly created OWA_Redirect virtual directory, and choose Properties.
2.	Under the Virtual Directory tab, in the Application Settings section, choose ExchangeApplicationPool from the drop-down box under Application pool as shown in Figure 12.14. Figure 12.14. Customizing the Application pool drop-down box.
3.	Select the Directory Security tab.
4.	Under Authentication and Access Control, click the Edit button.
5.	Keep the default checkbox checked for Enable Anonymous Access and accept the default anonymous account. Uncheck (do not enable) any other type of access.
6.	Click OK and OK to save the changes.

The last step is to actually change the 403.4 error message to use the custom ASP page. To do this, follow these steps:

1.	Under the same OWA Virtual Server in IIS Manager, right-click the Exchange virtual directory and choose Properties.
2.	Choose the Custom Errors tab.
3.	Select the HTTP Error of 403;4 and click the Edit button.
4.	Change Message type to URL, enter owa_redirect/owahttps.asp, and click OK.
5.	The Custom Errors dialog box should now look like the one shown in Figure 12.15. Click OK to save the changes. Figure 12.15. Customizing the 403;4 error to redirect OWA users to HTTPS.
6.	Right-click the server name and choose All Tasks, Restart IIS.
7.	Click OK to confirm the restart.

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.

NOTE

For more information on using this technique to redirect to SSL connections, reference MS KB article #555126 at the following URL:

http://support.microsoft.com/kb/555126

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. OWA Virtual Server Settings

Virtual Directory	SSL	Authentication	Notes
Root (at the virtual server level)	Not enabled	Anonymous only	Change home directory to redirect to URL /exchange. Check the check box for A Directory Below this One under the Home Directory tab.
Exadmin	Not enabled	Integrated Windows authentication	Not used for remote access; only needed to allow for public folders to be displayed when the local Exchange System Manager tool is accessed from the server.
Exchange	Required	Basic authentication only	Create custom 403.4 error to point to URL of /owa_redirect/ owahttps.asp.
ExchWeb	Required	Anonymous only	Note that enabling anonymous connections on this directory does not decrease security because the files themselves are secured.
Iisadmpwd	Required	Basic authentication only	Used to enable the Change Password feature in OWA, disabled by default in Exchange Server 2003. See the step-by-step examples in the section titled "Enabling the Change Password Feature in OWA Through an ISA Publishing Rule."
Microsoft-Server- ActiveSync	Required	Basic authentication only	Special considerations exist for OWA servers that are not dedicated front-end servers. See the subsequent Chapter 13.
OMA	Required	Basic authentication only	Special considerations exist for OWA servers that are not dedicated front-end servers. See Chapter 13.
ExchDAV	Not enabled	Integrated Windows authentication Basic authentication	Used only when OWA server is also a backend database server and SSL is enabled on the Exchange virtual server. This is for supporting OMA and EAS in this configuration, referenced in Chapter 13. Configure it to deny all connections except the local OWA server's IP address (for security reasons).
OWA_Redirect	Required	Anonymous only	Create this virtual directory and point to owahttps.asp redirect file.
Public	Required	Basic authentication only	Used for public folder access.
Rpc	Required	Basic authentication only	Used for RPC over HTTPS communications. See Chapter 13 for information on how to configure this.

NOTE

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.

CAUTION

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.