Step-by-Step:
Publishing a Single Exchange 2003 OWA with
ISA 2004 Firewall Forms Based Authentication by Liran Zamir
By Liran Zamir
Got questions? Discuss this article over at
http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=23;t=000106
I decided to take the DIY approach for setting ISA firewall to securely publish Exchange 2003 Outlook Web Access using forms-based authentication and SSL bridging to provide a higher level of security in web mail access. I believe this step-by-step article will take out some of the guess work that I went through when checking the configuration.
The procedures in this article will not work for multiple Exchange server environments as the publishing rule can only redirect request to a single server. If implemented in a multiple server environment, users will only be able to access OWA mailboxes located on the published server. I presume that in a multiple server environment the procedure could be configured only when the actual published server is an Exchange front-end server.
The advantage of publishing Exchange Outlook Web Access (OWA) using the ISA firewall’s Forms-Based authentication is the ability to off load the authentication of web clients from the Exchange server to the ISA firewall, and to prevent unauthenticated communication from reaching the Exchange server. The ISA firewall’s Forms-Based authentication works with Exchange 5.5, 2000 and 2003.
This article will focus on Exchange 2003, where a web site certificate is used for two purposes:
- Provide SSL communication between the remote client and the ISA firewall.
- Provide SSL communication between the ISA firewall and the Exchange server.
This will create an SSL to SSL bridge where the SSL communication from the remote client is terminated at the ISA firewall, and another SSL session is created between the ISA firewall and the exchange server. The remote client does not actually connect directly to the Exchange server over SSL.
Steps for deployment:
Preparing the Exchange server 2003 and certificates.
Decision point – Which certificates to use
Create your own certificates
Generating the web site certificate request
From a request to a certificate
Importing the certificates to the ISA firewall.
Checking SSL connectivity between the ISA firewall and the OWA site
Importing the certificates
Checking Browser connectivity from ISA to the OWA site
Configure the ISA Web Listener and Publishing rule.
Verify External connectivity.
Preparing the Exchange server 2003 and certificates.
NOTE!
Do not enable forms-based authentication on the Exchange server itself.
The first step to take is to configure your internal Exchange 2003 server to use a web site certificate for client connections. The clients may be internal or external network clients, as far as the Exchange server is concerned. Since in our case remote clients will actually connect to the ISA firewall, the ISA firewall itself will act as a client to the OWA web site. The Exchange server OWA web site can be configured to require SSL communication only, but this article will not cover this issue as it is usually not necessary to encrypt OWA connections within the internal network.
Decision point – Which certificates to use?
The best way to approach the use of certificates for a publicly accessible web site is to acquire a certificate from a known Certificate Authority such as Verisign.
The advantage of such certificate is that the issuer (the company which owns the certificate authority who generated the certificate) is already trusted by Windows based computers. You can use Internet Explorer’s Internet Options and Content tab to see the list of trusted certificate authorities. Another option is to open an mmc console and use the Certificates snap-in to view the list of Trusted Root Certificate Authorities.
If you cannot afford the purchase of a publicly signed certificate, you can issue your own certificates using a Windows 2000/2003 server, with the free Certificate Authority services within those network operating systems.
Note!
In some cases, such as when using the Exchange 2003 RPC over HTTP feature, you will be required to manually import the home-brewed CA certificate to the client computers in order for those computers to trust the unfamiliar Certificate Authority.
Create your own certificates
To issue your own certificate from a Windows 2003 server, use the following steps to install the required components.
Open Add/Remove programs, and select Add/Remove Windows components.
To make the process to issuing certificates easier, you should install both
the IIS server and the Certificate Services which include both the Certificate Authority installation and the Certificate Services Web Enrolment support.
During the installation process you will be asked to select which type of Certificate Authority you would like to install. If the sole reason you install the CA is to generate a web site certificate, select a “Stand-Alone root CA”. In a larger environment when PKI infrastructure is deployed you should check if an Enterprise root CA is installed – which will be able to issue the certificates.
Continue the installation process; provide a common name for the CA. I suggest you enter the public domain that you are using. In the following case I used my own registered domain name: liran.org
Accept the installation defaults and finish the installation.
When done, you will notice that on the CA server, a CA certificate is placed in the %windir%\system32\certsrv\CertEnroll folder. You will need to import the CA certificate to the trusted root Certificate Authorities store on the ISA firewall later on.
Generating the web site certificate request
Log on to the Exchange 2003 server you intend to publish. Open the Internet Information Services (IIS) Manager tool from the Administrative Tools menu, and expand the web sites tree. Locate and click Properties on the Default Web Site, which holds the OWA virtual directories. Select to the Directory Security tab, and click Server Certificate…. In the Wizard select: Create a new certificate.
Select to Prepare the request now, but send it later, and click Next. Leave the certificate name as Default Web Site, and the Bit Length: 1024 and click Next. Type the name of your organization and an OU, and click Next. In the Common Name window, make sure to enter the exact FQDN that will be used by external users to access the OWA web site. If the following example I used owa.liran.org. You should register this record with your publicly available DNS service provider for your domain. This record should point to the ISA firewall external interface IP address.
Note!
For smaller companies, the external IP address of the ISA firewall may already be configured on your public DNS for your domain as the MX record with a name such as mail.liran.org . When creating the certificate, you may use this record as the certificate common name, and save some time on calling the DNS provider for additional DNS record registration, but I will advise against it as you might want to set up a mail gateway in the future which will use the mail.liran.org as the MX record, but will no longer point to the ISA External interface IP address. The is no problem having more then one DNS record pointing to a single IP address, so just add another host record such as owa.liran.org.
Continue running the certificate wizard, enter additional information in the Geographical Information page. In the Certificate Request File Name page make sure to note the location and file name of the certificate request file. The default location is c:\certreq.txt. Continue the process and click Finish.
Form a request to a certificate
To approve the certificate request, open a web browser on the Exchange server and enter the URL to the CA server. For example:
http://CAServer/CertSrv (replace CAServer with the IP address or computer name of your CA server) On the Certificate Services Welcome screen, click Request a certificate. Select advanced certificate request, and click Submit a certificate request by using…. On the Submit a Certificate Request or Renewal Request page focus on the Saved Request window.
Open the request file generated earlier, (c:\certreq.txt), with notepad, and copy the content code between the Begin and End sections, and paste into the Saved Request window.
When done click Submit. Wait for the Certificate Pending, and close the web browser. Log on to the certificate server, open the Certification Authority console from the Administrative tools menu. Expand the CA, and navigate to the Pending Requests tree. On the right pane you will see the certificate request just waiting there to be approved. Right click the certificate and select All Tasks and then Issue. The issued certificate will be moved to the Issued Certificates container.
Go back to the Exchange server, and open the web browser. Again point to http://CAServer/CertSrv , and click View the status of a pending certificate request. Click the saved request certificate link, and select Download certificate using the DER Encoded. Save the file certnew.cer to the Exchange server desktop. Open the IIS console on the Exchange server, and again navigate to the Directory Security tab of the Default Web Site. Click Server Certificate… and use the wizard to process the pending request. Provide with the certnew.cer file, verify port 443 as the SSL port, click Next, Finish, and OK to close the properties page. Restart the Default web site.
At this point, the Default web site is SSL enabled, which means you can access it using either HTTP or HTTPS.
If you try to access the OWA web site using a web browser with https://, you might be prompted with an Alert such as the following one:
Note that the Alert contains three parts as explained:
a. Warning will appear if the CA that generated the certificate is not trusted.
In case you generated the certificate yourself from a privately installed CA,
you will need to import the CA certificate to the computer Trusted root
certificate authorities store. This is NOT required process on every client
unless you find this message very annoying.
b. Warning will appear if the certificate dates are invalid.
This could happen if the date scope of the certificate does not match
the date settings on the browsing computer, or if the certificate dates
themselves either will start in the future or already ended.
c. Warning will appear if contacting with a URL that is different for the
certificate common name.
In the above example I used the server NetBIOS name instead of
https://owa.liran.org/exchange, which caused the alert to appear.
In order for ISA firewall to properly publish the secured web site, you must make sure that SSL connection to the OWA web site will not fail any of the above tests. This will be covered later on.
Importing the certificates to the ISA firewall.
The ISA firewall will require the web site certificate with its private key to make client-to-ISA SSL connections, and ISA-to-OWA SSL connections. You should export a copy of web site certificate for a later use.
To do so, return to the Directory Security tab of the default web site on the Exchange server, and click View Certificate. On the certificate window, select the details tab, and click Copy to file. In the wizard, select Yes, export the private key, select to enable strong protection, set a password, and select to save the certificate to a file named c:\owasitecert.pfx. Copy the file to the ISA firewall hard drive. As I explained at the last section on step 1, the ISA 2004 server must be able to perform SSL client connectivity to the Exchange secured OWA site without any warning messages.
Checking SSL connectivity between ISA 2004 and the OWA site
Make sure SSL connection can be made from the ISA firewall to the Exchange server. Open a CMD console, and enter the following line to test SSL connectivity: telnet ExchangeIP 443. (Replace ExchangeIP with the Exchange server internal network IP address).
If a connection could not be made, create a computer definition for the Exchange server in the ISA console, and then create an access rule to allow HTTPS from LOCALHOST to the Exchange server computer object. Check connectivity again using telnet. When the connection could be made, continue by importing the required certificates to the ISA firewall.
Importing the certificates
On the ISA firewall, click Start -> Run, type mmc and click OK. In the new console either click CRTL+M, or select Add/Remove Snap-in from the file menu. On the Standalone tab, click Add, and select Certificates. Select Computer Account, and click Next. Select Local Computer and click Finish. Click Close and OK.
In the console, expand Certificates (Local computer), and navigate to Trusted root Certificate Authorities -> Certificates. Try to locate the Certificate server certificate. It should be named as your external domain name if you used my suggestion earlier for naming the CA. (This is not required if using 3rd party certificate) If you cannot find the certificate, you will need to import it. Copy the .crt file from the \system32\certsrv\CertEnroll folder of the Certificate authority server to the ISA firewall.
Back on the ISA firewall, right click the copied certificate, and select Install Certificate. Click Next, and select Place all certificates in the following store. Click Browse, enable Show physical stores, expand the Trusted root certificate authorities, and select Local Computer. Click OK, Next and Finish. You will be prompted with a security warning, click Yes, and OK to confirm the certificate installation.
To confirm the certificate installation, refresh the Trusted root Certificate Authorities certificate list and verify the certificate can be located.
Keep the certificate console open on the ISA firewall.
Next, you will need to import the Web site certificate to the ISA firewall.
Use the certificates console again.
In the Console tree, expand Certificates (Local Computer), and select the Personal container. Right click Personal and select All Tasks -> Import. Use the Browse to locate the owasitecert.pfx file you copied from the Exchange server earlier, provide the password, and place the imported certificate to the personal certificate store. When down, refresh the personal store and locate the imported web site certificate under Personal -> Certificates.
The certificate will be named based on the Common Name you selected for the published web site.
Close the Certificates console. You are not required to save it.
Checking Browser connectivity from ISA to the OWA site
Now we will check if the ISA firewall can connect to the OWA web site. As explained on the first section of the article, a few checks are made when connecting to a site with an SSL certificate.
We already covered the importing of the CA certificate to the ISA firewall, so the CA should already be trusted.
I assume that the web site certificate dates are valid as well as the date/time configuration on the ISA firewall clock, so we are only left with making sure that the URL used to connect to the OWA site is the one specified in the common name. This means that in our lab case, we should be able to resolve the URL owa.liran.org from the ISA firewall to the Exchange server internal IP address.
If the ISA firewall cannot resolve the common name (owa.liran.org) to the Exchange IP address using DNS, (test by performing a ping command), you should edit ISA firewall’s hosts file (located in the %systemroot%\SYSTEM32\DRIVERS\etc folder) to include a name to IP translation of the common-name FQDN to the Exchange IP address. After updating the HOSTS file, try to ping the FQDN again, and verify that the ping request indeed tries to ping the Exchange IP address. Note that we are looking for a successful name resolution and not a successful ping as ping traffic might be blocked by the ISA firewall default rule.
Open a web browser on the ISA firewall, and enter the URL for test. The URL should be in the form of:
https://common-name/exchange (You should replace the common name with the actual FQDN). If you are getting the Security Alert message, you should resolve the cause of the problem and try again. If you are unable to access the site at all, disable any web proxy settings in the browser LAN Settings and try again. Do NOT delete the added entry to the hosts file!
After resolving any problems you might have, you will be able to connect and logon to a mailbox on the Exchange OWA web site using basic authentication pop-up window. Form based authentication will be performed for remote clients by the ISA firewall.
Configure the ISA 2004 Listener and Publishing rule
In our example, the ISA firewall is configured with two network adapters. The first adapter connects to the LAN and the second adapter to the Internet. To publish the OWA web site, we will open the ISA management console, and navigate to the Firewall Policy on the left pane. On the right pane, expand the Task Pane. Click Publish a mail server on the Tasks tab. The Welcome to the new mail server publishing rule wizard will appear. Select your desired rule name and click Next. Select Web Client Access, and click Next. On the Select Services page, make sure that Outlook Web Access is selected and click Next.
On the Bridging Mode page select Secure Connection to client and mail server.
On the Specify the Web Mail Server page, type the FQDN of the published site (not the IP address, not the NetBIOS name and not the internal domain FQDN unless the full server name of the Exchange server in the internal Active Directory DNS matches the Common name FQDN, which is not likely).
On the Public Name Details page, enter the FQDN again, and click Next.
On the Select web Listener pane either edit an existing listener or create a new Listener in case no listener exists.
Configure the listener to listen on the External network segment. You can use the Address option to specify the specific external IP address to listen to in case you got multiple external IP addresses.
On the Port Specification page, enable SSL on port 443 and clear “Enable HTTP”. Click Select to select the web site certificate that will be used for the client secure connection. If clicking Select results with no certificates, you should either close and reopen the ISA console (it might have been open when you imported the certificate), or re-check the certificate existence in the Personal certificate store of the Local Computer. Click Next and Finish to close the Listener configuration. Back in the Select Web Listener page, click Edit to edit the listener further more.
On the Preferences tab click Authentication.
Remove the Integrated selection, and select the OWA forms-Based instead. Click OK twice to confirm the Listener configuration and return to the Select Web Listener page. Click Next twice to make the rule apply to all users, and click Finish. Back in the ISA console, click Apply to activate the new rule.
Verify External connectivity.
The final step is to make sure that external clients can indeed access the OWA web site. Connect a computer to the Internet, and ping the web site common name. The name should be resolved to the ISA firewall external interface IP address that you specified on the listener. If the name could not be resolved by the public DNS service for your domain, verify that the record was registered with the ISP/DNS service provider. To temporarily overcome the record registration issue, update the client HOSTS file to provide the name-to-IP translation, where the common name translates to the ISA External IP address.
After name resolution is available, open a web browser and connect to the URL, for example: https://owa.liran.org/exchange
Note!
As the Web Publishing rule is configured to answer requests directed specifically to the FQDN in addition to the specific Exchange virtual directories, no other URL entered will allow you to access the OWA site.
Other requests will be answered with the error message: Error Code: 403 Forbidden. The server denied the specified Uniform Resource Locator (URL). Contact the server administrator. (12202)
A successful connection attempt will probably provide with the following Security Alert, as the CA certificate is unknown to the external client.
Disregard this warning, by clicking Yes.
If your users are concerned with this message either install the CA certificate on each remote computer (which might not be possible in every Internet Café in Bangkok), or get yourself a web certificate from a trusted CA.
The users will now be instructed to provide logon information using the form based authentication page provided by the ISA firewall. The transport of the user credentials are encrypted by SSL 128bit encryption.
Voila! We are there. Enjoy your secure Outlook Web access solution.
If you find any faults in this article you are welcome to contact me at:
We hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=23;t=000106 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom
If you would like us to email you when Liran Zamir releases another article on ISAserver.org, subscribe to our ‘Real-Time Article Update’ by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy.
