Executive Summary:
| Get instructions for publishing Microsoft Outlook Web Access (OWA) hosted on a Microsoft Exchange Server 2007 Client Access server to Internet users through Microsoft ISA Server 2006. Once you've published OWA, you use similar steps for publishing other Exchange services such as Outlook Anywhere (previously known as remote procedure call—RPC—over HTTP), Exchange ActiveSync, Autodiscover, and other applications such as Outlook Express and Outlook Express's Windows Vista successor, Windows Mail. The final step is publishing the Exchange Edge Transport server on ISA Server to communicate with other SMTP servers on the Internet. |
One of the most important tasks that administrators of almost every network face is providing remote and mobile users access to internal resources, especially email services. Microsoft Exchange Server 2007 has several services that users can access over the Internet, and if improperly configured, they can pose a significant security risk. However, you can securely publish Exchange 2007 services through Microsoft ISA Server 2006. I'll show you how.
ISA Server Proxies Exchange 2007 Client Access and Edge Transport Servers
ISA Server offers proxy and reverse-proxy functionality, application-level filtering, and intrusion detection to secure Exchange 2007 services from malicious users, as well as provide corporate users the proper level of access.
An Exchange 2007 installation can have multiple server roles in an organization. In the scenario I describe here, ISA Server makes Exchange 2007's Client Access server role and Edge Transport server role available to Internet users and to other SMTP servers. The Client Access server role uses HTTP, HTTP Secure (HTTPS), and optionally POP3 and IMAP; the Edge Transport server role uses only SMTP, and DNS for name resolution. Exchange 2007–related services that use these protocols are Outlook Web Access (OWA), Outlook Anywhere (previously known as remote procedure call—RPC—over HTTP), Exchange ActiveSync, Autodiscover, and applications such as Outlook Express and Outlook Express's Windows Vista successor, Windows Mail.
The first step is to configure the Exchange 2007 servers that you want to be accessible from the Internet as Secure Network Address Translation (NAT) clients of ISA Server. To do so, you set the servers' default gateway to the internal IP address of the ISA Server system or route the servers to ISA Server's internal network adapter through a network router.
When you use ISA Server, all client connections are terminated on ISA Server, which presents itself as Exchange Client Access server to clients. It accepts client connections, asks clients for authentication information, pre-authenticates them, inspects message content, and creates a new, encrypted connection to a real Client Access server on the internal network on behalf of the user. Let’s look first at the scenario of publishing OWA hosted on an Exchange 2007 Client Access server to Internet users. Once you've published OWA, you use similar steps for publishing other services. The final step is publishing the Edge Transport server on ISA Server to communicate with other SMTP servers on the Internet.
Preparing the Certificates
In order to have encrypted connections between clients, ISA Server, and Exchange 2007 Client Access server, you must install an SSL certificate on ISA Server and on Client Access server. Because ISA Server will “pretend” to be Client Access server, its certificate must have the same name as the Client Access server's certificate.
One way to get a certificate with the same name on both servers is to export the certificate from Client Access server and install it on ISA Server. By default, Client Access server will have a self-signed certificate, but you should replace this default certificate with a certificate issued by your corporate Certificate Authority (CA) or, even better, by a commercial CA. The reason for replacing the self-signed certificate is that user applications won't trust it and will display warning messages, although the encryption will work.
There are two methods for getting a new certificate for Client Access server. You can access the Certificate Request wizard from the Microsoft Management Console (MMC) Certificates snap-in to request and get a certificate from an online CA, or you can use the Exchange Management Shell for preparing a certificate request that you'll later submit to a CA. One good reason for using EMS instead of the Certificates snap-in is if you want to have multiple host names (aka subject alternative names or subject names) in one certificate—for example, if you want to publish OWA and Autodiscover on the same site. You can do this only through EMS, by entering a command with the following syntax:
New-ExchangeCertificate -generaterequest -subjectname "dc=local,dc=domain1, o=Organization Name,cn=exchange.domain1.local" -domainname CAS01,CAS01.exchange.domain1.com, exchange.domain1.local,autodiscover.domain1.com -path c:\certrequest_cas01.txt
This command prepares a text file that can be used for requesting a certificate for a server named exchange.domain1.local, from domain1.local, with the subject names specified after the -domainname switch.
You can submit the request to a domain CA by using the Certificates snap-in or the Web Enrollment page, choosing Advanced certificate request, and then clicking Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file. Web enrollment for certificates is available if the Web Enrollment component is installed on the domain CA. You can access the Web Enrollment page by typing http://CAname/certsrv. However, automatic issuance of certificates requested via Web Enrollment will be available only if an Enterprise CA is installed.
Installing a certificate is simple. If you requested the certificate via the Certificates snap-in or by Web Enrollment from an Enterprise CA, it will be installed automatically unless an administrator has prevented automatic issuance. If you sent a request created with EMS, requested a certificate from a standalone CA in your environment, or bought a commercial certificate, then you should import the certificate into the local computer account certificate store in the Certificates snap-in. I describe importing a certificate on ISA Server below.
After installing a certificate, you can use the MMC IIS snap-in to assign the certificate to the default Web site. To do so, start the IIS snap-in, expand Web Sites, right-click Default Web Site, select Properties, and go to the Directory Security tab. Click Server certificate to start a wizard for managing certificates. Choose the options for replacing the current (self-signed) certificate and specify your new certificate as the replacement.
Next you want to export the new certificate to ISA Server. Open the IIS snap-in on Client Access server, expand Web Sites, and right-click Default Web Site. Choose Properties, go to the Directory Security tab, and click View Certificate. On the Details tab, click the Copy to file option, which starts the wizard for exporting the certificate. Select the option to export the private key, enable the strong key protection, and export the full certificate path. Save the certificate in .pfx format and copy the file to a folder on ISA Server.
On ISA Server, click Start, Run, type mmc.exe to open MMC, and add the Certificates snap-in. At the screen that appears after you add the snap-in, choose Computer account; then click Next, and select Local Computer. Back at the Certificate snap-in's main screen, expand Certificates - Personal. Right-click Personal and select All Tasks, Import to start the Certificate Import wizard. Browse to the .pfx file copied from Client Access server, enter the password for strong key protection, don't enable the option for marking the key as exportable, and finish the wizard. The certificate from Client Access server is now installed on ISA Server.
For more information about installing and using certificates with Exchange, see the Exchange & Outlook UPDATE articles "Certificates and Exchange, Part 1" (http://www.windowsitpro.com/Articles/ArticleID/93440/93440.html), "Certificates and Exchange, Part 2" (http://www.windowsitpro.com/Articles/ArticleID/93517/93517.html), and "Certificates and Exchange, Part 3" (http://www.windowsitpro.com/Articles/ArticleID/95067/95067.html) and "Managing SSL for a Client Access Server" (http://technet.microsoft.com/en-us/library/bb310795.aspx).
Publishing OWA
Now, you're ready to configure an ISA Server publishing rule for OWA. Open the ISA Server 2006 Management console, expand the Firewall Policy node, and in the right pane, click Tasks. Click Publish Exchange Web Client Access, which starts the New Exchange Publishing Rule wizard. Enter a name for the rule (such as Exchange 2007 OWA), then choose Exchange Server 2007 from the drop-down list, and select the Outlook Web Access option, as Figure 1 shows.
Next, select the option for publishing a single Web site or load balancer, depending on your setup. Then, select the option to use SSL for communication between ISA Server and the published server.
Enter the internal DNS name of the published site and optionally the name or local IP address of the Client Access server, as shown in Figure 2. The internal name is the Fully Qualified Domain Name (FQDN) that you use to access Client Access server from your internal network. Entering the internal host name or IP address is a good idea if your ISA Server can't resolve names for local resources.
Next, enter the public name of your Exchange server (i.e., the name that clients from the Internet will use). This name must match the name configured in the Exchange server's OWA options and on the Client Access server certificate. Select the This domain (type below) option from the drop-down list, and enter the name.
Now we have to create a listener for this publishing rule. The listener component is very important because it handles authentication and encryption. Click New on the Select Web Listener page of the New Exchange Publishing Rule wizard to start the New Web Listener Definition wizard, and enter the name for the listener. Select the option to require SSL with clients, as Figure 3 shows.
Next, you specify the ISA Server IP address on which the listener will work. Typically, you can select External as the network for all available IP addresses. If you have multiple public IP addresses on your ISA Server and you want the listener to work on only one of them, you can click Select IP Addresses and choose the specific IP address on which you want to publish this service. Note that the IP address you select here is bound to the listener you’re creating. You can still use it for publishing other services, but only with the same listener. On this page, you can also select the option for compressing content sent to clients; compression will be applied only on clients that support it.
After you’ve selected the correct IP address, choose the Use single certificate for this web listener option and click Select Certificate. From the certificate list, choose the one you imported from Client Access server earlier.
On the Authentication Settings page of the New Web Listener Definition wizard, expand the drop-down list of authentication options, as Figure 4 shows. The first option, HTML Form Authentication, configures ISA Server to present clients with an authentication Web page. If you select this option, you must disable form authentication on your Exchange 2007 Client Access server.
I recommend using ISA Server's form authentication. Form-based authentication uses cookies in the client's browser to control the client session. Also, depending on whether the user specifies a private or public computer on the authentication page, form authentication terminates the session after a longer or shorter period of inactivity and handles email message attachments differently. Form authentication can be used for all Exchange Web services, is a very secure solution, and requires no additional setup on the client. However, you should use Microsoft Internet Explorer (IE) 6.0 or later on the client to take full advantage of OWA functionality. ISA Server form authentication adds the benefit of letting you provide single sign-on (SSO) functionality for your clients, which you can't achieve by using Exchange form-based authentication.
Also on the Authentication Settings page, select Windows (Active Directory) as the authentication method if your ISA Server is a domain member, LDAP (Active Directory) or RADIUS if it isn't.
The last Web listener definition step is to configure SSO functionality. This step is available only if you selected HTML Form Authentication earlier. By using SSO, you allow ISA Server to delegate client credentials to all published resources that are using this listener. The client will need to authenticate only once—on ISA Server. If you enable this option, and I recommend that you do, you must also enter your domain name.
Finishing the New Web Listener Definition wizard returns you to the New Exchange Publishing Rule wizard's Authentication Delegation page. You must configure the method that ISA Server will use to delegate client credentials to the Client Access server. Because you selected form authentication on the Web listener, you should choose Basic authentication (in fact, it's Basic with SSL). This means that ISA Server will use SSL to encrypt the credentials before passing them to the Exchange server.
Next, you must select the group of users that will be allowed to use the OWA service. Leave the default Authenticated users setting unless you have a specific reason to change it.
At the end of the New Exchange Publishing Rule wizard, ISA Server warns you to configure the Exchange server authentication to be compatible with the ISA Server authentication, as Figure 5 shows. Doing so is very important. On the Client Access server, open the Exchange Management Console, expand the Server Configuration node, select Client Access, go to the Outlook Web Access tab, right-click the owa virtual folder, select Properties, go to the Authentication tab, and select Use one or more standard authentication methods and Basic authentication (password is sent in clear text), as Figure 6 shows. This will configure the Exchange server to accept delegated user credentials from ISA Server in Basic-with-SSL form. You can also choose Integrated Windows authentication for clients from the internal network who access OWA. It's worth mentioning that the owa Properties dialog box also lets you configure a shared folder and SharePoint access through OWA, which is a very cool feature of Exchange 2007.
Back on the ISA Server system, you might want to configure a few more options on your new rule and listener. In the ISA Server 2006 Management console, find your new publishing rule under the Firewall Policy node and double-click it to open it. On the Traffic tab, you can configure a requirement for 128-bit encryption.
On the rule's Listener tab, click Properties and go to the Forms tab, and you'll see some additional options for ISA Server form-based authentication, as Figure 7 shows. You can allow users to change their passwords after they log on to ISA Server by using form authentication (a useful option for services that don't have this ability integrated like OWA does) and use a custom form instead of the default form. Click Advanced to configure cookie settings, as Figure 8 shows.
When users enter the URL for your OWA service, they'll see a form authentication page that's slightly different from the one that Exchange 2007 builds. As Figure 9 shows, the page includes an option for changing the user password and a note that Exchange is protected by ISA Server.
The only configuration you need to do on the client side to use Exchange services through ISA Server is to specify a proxy server URL and an authentication method. To do so, open the Control Panel Mail applet, click E-mail Account, and double-click the user's Exchange account. Click More settings, go to the Connection tab, and click Exchange proxy settings. The proxy server URL is the public name of your Exchange server, and the authentication method (under Proxy authentication settings) is Basic Authentication.
Also in the Microsoft Exchange Proxy Settings dialog box, you can configure the client to choose between a TCP/IP (Messaging API—MAPI) connection and an HTTPS connection based on network speed. Typically, you'll want Outlook to use an RPC-over-HTTPS connection when the user is connecting over a slower Internet link and classic TCP/IP MAPI when the user is on the network on which the Exchange server resides.
Finally, note that clients must trust the CA that issued the certificate for ISA Server and Client Access server. Also, the public name of the Exchange server that Internet clients use must resolve to the public IP address of ISA Server that you previously bound to the listener. You'll need to create the proper host records in your public DNS server to make this happen.
Handling Multiple Sites
If your organization has more than one physical site, each with its own Client Access server, you can use the same procedure to publish each server. In this scenario in which all Client Access servers are published to the Internet, users can connect to any Client Access server and they'll be redirected to the server at the site where their mailbox resides.
However, if you have multiple sites and multiple Client Access servers, but you want to publish only one Client Access server to the Internet, the server that contains a particular user's mailbox might not be accessible from the Internet. When a user connects to a Client Access server that doesn't contain his or her mailbox, the server will use the client protocol to proxy the client request to the Client Access server at the site where the user’s mailbox is located. In order for the Client Access server to proxy the client request, you must configure the Client Access servers that aren't accessible from the Internet to use Integrated Windows authentication. The server that's published through ISA Server should use Basic authentication, as explained earlier.
Publishing Other Exchange Services
You use the same wizard as you did with OWA (just selecting a different option at the beginning) and the same listener component to publish Outlook Anywhere or Exchange ActiveSync. For either of these services, start the New Exchange Publishing Rule wizard; select the Outlook Anywhere option or Exchange ActiveSync option; use the listener configured earlier; and on the wizard's Authentication Delegation page, use Basic authentication.
As with OWA, you must also configure Basic authentication on the Exchange side and configure the Exchange server's public name on the DNS server. To use Outlook Anywhere, your clients must use Outlook 2007 or Outlook 2003 on Windows Vista or Windows XP SP2.
Publishing the Edge Transport Server
The only thing left to be done is to provide SMTP communication between ISA Server and Edge Transport server. It's a simple, two-step job.
In the ISA Server 2006 Management console, select the Firewall Policy node, click Tasks, and start the Mail Server Publishing wizard. Select the SMTP service, enter the IP address of Edge Transport server, and select the ISA Server IP address that will forward SMTP traffic to the Edge Transport server.
You also have to create an access rule on ISA Server that allows only the SMTP and DNS protocols from the Edge Transport server to the external network and that specifies the All users group on the User sets page of the New Access Rule wizard. The latter setting is necessary because ISA Server's Secure NAT client can't provide credentials.
There are many reasons to use ISA Server 2006 for securing and publishing the Exchange 2007 services. Besides providing firewall protection for your internal network, ISA Server can make Exchange services as secure as possible and can even offload some tasks, such as encryption and authentication, from Client Access server. If you need to let mobile users secure access to email or synchronize their Windows Mobile devices with their computer on the network, this guide should help you accomplish that.