Publishing Secure Exchange 2003 Outlook Web Access Sites with ISA Server 2000

 

Remote users can connect to your Exchange Server from virtually any site in the world using the HTTP protocol using Outlook Web Access (OWA). Exchange Server 2003 takes OWA to the next level. The Exchange Server 2003 OWA site provides much greater functionality than the Exchange 2000 OWA site and provides a user experience very close to what you see with the full Outlook MAPI client.

 

Note:

Secure Exchange RPC Publishing is inherently more secure than OWA. The sophisticated layer 7 RPC filter tightly secures the connection between the remote full Outlook MAPI client and Exchange Server. However, many remote users are behind conventional firewalls that do not allow outbound MAPI access to your Exchange Server because they lack the layer 7 intelligence provided by ISA Server firewalls.

 

OWA Web site publishing provides a viable alternative, both in terms of level of functional and level of security, to secure Exchange RPC Publishing. Your challenge as the ISA Server 2000 firewall administrator to provide remote users access to your Exchange Server 2003 OWA site and do so in a secure fashion.

 

Fortunately, it is possible to provide remote users a highly secure connection to your corporate OWA Web site. Security technologies that assure a protected link between the remote user and the OWA Web site include:

 

 

Secure OWA Web site publishing using ISA Server 2000 provides a higher level of security than virtually any other firewall on the market and provides a level of functionality and security second only to secure Exchange RPC Publishing.

 

You need to carry out the following procedures to create a highly secure remote access OWA Web site publishing solution:

 

 

The remainder of this ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document discusses the details of each of these steps.

 

 

 

Install the Exchange Server

 

There are no special installation requirements on the Exchange Server to allow OWA publishing to work correctly with ISA Server. As long as the OWA site is operational for internal network clients, it will be operational via ISA Server 2000 Web Publishing Rules.

 

 

Install an enterprise CA on the internal network

 

An enterprise Certificate Authority (CA or Certificate Server) has several advantages over a standalone CA. Two of the primary advantages of using an enterprise CA is that you can use autoenrollment to automatically deploy machine and user certificates to all domain members. In addition, you can use the Certificates MMC stand-alone snap-in to request and install a certificate from an online enterprise CA.

 

You can install an enterprise CA on a domain member in the same domain as the front-end Exchange Server and the ISA Server 2000 firewall. This configuration allows you to request Web site certificates for the OWA, POP3 and IMAP4 sites from an online certificate authority and install them immediately.

 

In addition, all Exchange Servers and the ISA Server 2000 firewall can request certificates from the online enterprise CA and install them immediately. This simplifies the task of creating the SSL link between the ISA Server 2000 firewall and the front-end Exchange Server as well as making it easier to create a working IPSec Policy based on certificate authentication to secure the communications between the front-end and back-end Exchange Servers.

 

Please refer to ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document Creating the enterprise CA for more information on how to create an enterprise CA and ISA Server 2000 Exchange Server 2000/2003 Deployment Kit documents Issuing certificates via the MMC snap-in and Issuing certificates via autoenrollment

 

 

Issue and bind certificates for the OWA site

 

Your goal is to provide secure remote access for your remote OWA clients. You can provide secure access by requiring these clients to use SSL/TLS encryption when connecting to the Exchange Server. All communications moving through the secure channel are protected by TLS encryption (including basic authentication credentials.

 

The published Web site requires a Web site certificate. The Web site certificate is placed in the Exchange Server’s machine certificate store and bound to the Exchange Server’s Web site.

 

Please refer to ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document

How to Obtain a Web Site Certificate for details on how to obtain, install and bind the Web site certificate to the Exchange services you wish to publish.

 

Note:
It is critically important that the common name on the certificate is the same as the name the OWA client uses to access the service. For example, remote browsers must use the FQDN owa.domain.com when connecting to the OWA Web site when the name on the certificate is owa.domain.com. This name must also resolve to the IP address on the external interface of the ISA Server that you’ve configured to listening for incoming connections to the OWA site.

 

 

 

Export the OWA site certificate to a file

 

The ISA Server 2000 firewall computer performs SSL to SSL bridging to protect the connection from the remote OWA client end to end. This end to end protection is important because the implicit assumption made by the remote host is that if the initial connection requires a secure link, then the entire transaction is protected by an encrypted link.

 

SSL to SSL bridging allows the external Web browser to create an encrypted SSL link with the external interface of the ISA Server 2000 firewall. The ISA Server firewall decrypts the packets and inspects them for validity and drops invalid packets. The ISA Server firewall then establishes a second SSL session between its own internal interface and Exchange Server, re-encrypts the packets and forwards them to the Exchange server.

 

The ISA Server 2000 firewall impersonates the OWA Web site by presenting the OWA Web site’s certificate to the remote OWA client. The name of the OWA Web site is contained in the certificate; this is the mechanism of impersonation.

 

Perform the following steps to export the Web site certificate from the OWA server:

 

  1. Click Start, point to Administrative Tools and click on Internet Information Services. In the Internet Information Services (IIS) Manager console (figure 1), expand the Web Sites node and click on the Default Web Site entry. Right click on Default Web Site and click Properties.

 

Figure 1

 

  1. Click on the Directory Security tab in the Default Web Site Properties dialog box (figure 2). Click on the View Certificate button.

 

Figure 2

 


  1. In the Certificate dialog box, click on the Details tab (figure 3). Click on the Copy to File button.

 

Figure 3

 


  1. Click Next on the Welcome to the Certificate Export Wizard page (figure 4).

 

Figure 4

 


  1. Select the Yes, export the private key option on the Export Private Key page (figure 5). Click Next.

 

Figure 5

 


  1. On the Export File Format page (figure 6), select the Personal Information Exchange – PKCS #12 (.PFX) option. Put a checkmark in the Include all certificate in the certification path if possible checkbox. Remove the checkmarks from the Enable strong protection (requires IE 5.0, NT 4.0 SP4 or above) and Delete the private key if the export is successful checkboxes.

 

The enable strong protection option requires user intervention before the certificate can be used to establish a connection. The server on which the certificate is installed cannot perform the required actions. That is why you must not select that option. You do not want to delete the private key from the OWA site, because you want to keep the key there for backup.

 

Click Next.

 

Figure 6

 


  1. On the Password page, type a password and confirm the password. This password protects the private key from being stolen by anyone who might obtain the exported file (figure 7).

 

Figure 7

 


  1. On the File to Export page (figure 8), type in a path and file name for the certificate file. Remember where you store the file because you need to copy it to the ISA Server machine in the DMZ. Click Next.

 

Figure 8

 


  1. Review your settings on the Completing the Certificate Export Wizard page (figure 9) and click Finish.

 

Figure 9

 


  1. Click OK on the Certificate Export Wizard dialog box that informs you the export was successful (figure 10).

 

Figure 10

 


  1. Close the Certificate dialog box (figure 11).

 

Figure 11

 


  1. Close the Default Web Site Properties dialog box (figure 12).

 

Figure 12

 

 

 

Configure the OWA Site to Force SSL Encryption and Basic Authentication

 

The OWA Web site supports SSL connections as soon as the certificate is bound to the site. However, users still have the option to connect to the site using a non-secure connection. You can force both the ISA Server and internal users to use an SSL connection to the OWA Web site directories. You can require all clients to successfully negotiate an SSL link before connecting to the OWA site directories.

 

We also want to force basic authentication on all OWA directories the ISA Server makes accessible to external users. This allows you to take advantage of the ISA Server 2000 Feature Pack 1 feature that allows relay of basic authentication credentials from the firewall to the OWA site. This prevents all non-authenticated communications from reaching the OWA Web site and significantly improves the level of security.

 

Perform the following steps to force an SSL connection to the OWA Web site directories:

 

1.       Click Start, point to Administrative Tools and click on Internet Information Services. In the Internet Information Services (IIS) Manager (figure 13), expand your server name and then expand the Default Web Site node in the left pane of the console.

 

The three OWA Web site directories that you will make accessible to remote users are:

 

/Exchange

/ExchWeb

/Public

 

We want the ISA Server to always negotiate an SSL connection when proxying communications between these directories and the remote OWA client.

 

Start by clicking on the Exchange directory so that it is highlighted. Then right click on an empty area in the right pane of the console. Click the Properties command.

 

Figure 13

 

2.       Click on the Directory Security tab (figure 14). In the Authentication and access control frame, click on the Edit button.

 

Figure 14

 

3.       In the Authentication Methods dialog box (figure 15), remove the checkmark from all checkboxes except for the Basic authentication (password is sent in clear text) checkbox. Place a checkmark in the Basic authentication checkbox. Click Yes in the dialog box warning you that the credentials should be protected by SSL. Type in your domain name in the Default domain text box.

 

Click OK.

 

Figure 15

 

4.       Click Apply and then click OK in the Exchange Properties dialog box (figure 16).

 

Figure 16

 

5.       Repeat these steps with the /Exchweb and /Public directories found in the left pane after the console. Close the Internet Information Services (IIS) Manager console (figure 17) when you have forced basic authentication on the Exchange, Exchweb and Public folders.

 

Figure 17

 

 

The next step is to force the ISA Server’s Web Proxy service to use SSL when connecting to the OWA directories. Perform the following steps to force all connections to the OWA directories to negotiate an SSL connection:

 

1.       Click Start, point to Administrative Tools and click on Internet Information Services. In the Internet Information Services (IIS) Manager (figure 18), expand your server name and then expand the Default Web Site node in the left pane of the console.

 

Now you will force an SSL connection on the directories the remote OWA users will access though the ISA Server. These directories are:

 

/Exchange

/Exchweb

/Public

 

Click on the Exchange node in the left pane of the console to highlight it. Right click on an empty area in the right pane of the console and click the Properties command.

 

Figure 18

 

2.       Click on the Directory Security tab in the Exchange Properties dialog box (figure 19). Click the Edit button in Secure communications frame.

 

Figure 19

 

3.       In the Secure Communications dialog box (figure 20), put a checkmark in the Require secure channel (SSL) checkbox. Put a checkmark in the Require 128-bit encryption checkbox. Click OK.

 

Figure 20

 

4.       Click Apply and then click OK on the Exchange Properties dialog box (figure 21).

 

Figure 21

 

5.       Repeat the procedure to force an SSL connection on the Exchweb and Public directories in the left pane of the console. Close the Internet Information Services (IIS) Manager console after forcing SSL on the Exchange, Exchweb and Public directories.

 

 

 

Configure the OWA Site to Require Client Certificate

 

You can further enhance the security provided to the connections clients make to the OWA directories by configuring the OWA directories to require a host to provide a client certificate before allowing the connection. The OWA client must provide user credentials via basic authentication and must also present a client certificate. You can assign internal network clients certificates via group policy if you have internal network clients that need to access the Exchange Server via OWA.

 

This ISA Server does not have a logged on user that presents a client certificate to the OWA Web site directories. Instead, you obtain a user certificate for the Web Proxy service and then import the certificate into the ISA Server 2000 Web Proxy service’s Personal\Certificates certificate store. Next, you configure the OWA Web Publishing Rule to present a client certificate to the OWA Web site after the certificate is imported into the Web Proxy service’s certificate store.

 

Please refer to ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document

Increasing OWA Security by Configuring the ISA Server to Present a Client Certificate to an OWA Web site for detailed information on how to configure the OWA Web site to require a user certificate and how to configure the ISA Server’s Web Proxy service to present a user certificate to the OWA site.

 

Note:
User authentication is performed via basic authentication. The OWA directories are configured to require the client to present a client certificate, but this certificate is not mapped to a user account and the client certificate is not used to authenticate the client. It is the information send with the basic authentication credentials that determines the mailbox that is opened.

 

 

 

Install Windows Server 2003 on the firewall computer

 

The computer that becomes the ISA Server 2000 firewall must meet the following minimum requirements:

 

 

The ISA Server firewall and Web caching components work very well on modest hardware. This is true even when the SMTP filter is enabled and protecting published SMTP servers. However, if you run decide to use the SMTP Message Screener on the firewall, or if you use SSL to protect Web Published Web site, or if you use the ISA Server firewall as a VPN server, you need to increase the minimum requirements to support encryption services.

 

 

Install ISA Server 2000 on the firewall computer

 

Install ISA Server 2000 after installing Windows Server 2003 onto the firewall computers. You must go through some specific procedures outside of the standard ISA Server 2000 installation when installing the firewall software onto a Windows Server 2003 computer. Please refer to ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document Installing ISA Server 2000 on Windows Server 2003.

 

 

 

Import the OWA Web Site Certificate into the ISA Server Firewall’s Machine Certificate Store

 

Now that the ISA Server software is installed, you’re ready to copy the Web site certificate file from the Exchange Server to the ISA Server. The OWA Web site certificate is imported into the ISA Server’s machine certificate store. Then the imported certificate is bound to the Incoming Web Requests listener.

 

Perform the following steps to import the OWA server’s Web site certificate into the ISA Server’s machine certificate store:

 

1.       Click Start and click on the Run command. Type mmc in the Open text box and click OK. In the Console 1 console, click the File menu and click the Add/Remove Snap-in command (figure 22).

 

Figure 22

 

2.       Click the Add button in the Add/Remove Snap-in dialog box (figure 23).

 

Figure 23

 

3.       Click on the Certificates entry in the Available Standalone Snap-in list on the Add Standalone Snap-in dialog box (figure 24). Click Add.

 

Figure 24

 

4.       Select the Computer account option on the Certificates snap-in page (figure 25). Click Next.

 

Figure 25

 

5.       On the Select Computer page, select the Local computer: (the computer this console is running on) option and click Finish (figure 26).

 

Figure 26

 

6.       Click Close on the Add Standalone Snap-in page (figure 27).

 

Figure 27

 

7.       Click OK on the Add/Remove Snap-in dialog box (figure 28).

 

Figure 28

 

8.       Right click on the Personal node in the left pane of the console, point to All Tasks and click Import (figure 29).

 

Figure 29

 

9.       Click Next on the Welcome to the Certificate Import Wizard (figure 30).

 

Figure 30

 

10.   Click the Browse button and locate the certificate file. Click Next after the file path and name appear in the File name text box (figure 31).

 

Figure 31

 

11.   On the Password page, type in the password for the file (figure 32). Do not put a checkmark in the Mark this key as exportable. This will allow you to back up or transport you keys at a late time checkbox. The reason is that this machine is a bastion host with an interface in a DMZ or on the Internet and may be compromised. The compromiser may be able to steal the private key from this machine if it is marked as exportable.

 

Click Next.

 

Figure 32

 

12.   On the Certificate Store page (figure 33), confirm that the Place all certificate in the follow store option is select and that is says Personal in the Certificate store box. Click Next.

 

Figure 33

 

13.   Review the settings on the Completing the Certificate Import page and click Finish (figure 34).

 

Figure 34

 

14.   Click OK on the Certificate Import Wizard dialog box informing you the import was successful (figure 35).

 

Figure 35

 

15.   You will see the Web site certificate and the CA certificate in the right pane of the console. The Web site certificate has the FQDN assigned to the Web site. This is the name external users use to access the OWA site. The CA certificate must be placed into the Trusted Root Certification Authorities\Certificates store so that this machine will trust the Web site certificate installed on it.

 

Double click on the Web site certificate in the right pane of the console (figure 36).

 

Figure 36

 

16.   Click on the Certification Path tab on the Certificate dialog box (figure 37). Notice the red “x” on the CA certificate node. This indicates that this machine does not trust the CA that issued the Web site certificate. In order to use this certificate to perform SSL to SSL bridging, this machine must trust the CA that issued the Web site certificate.

 

Close the Certificate dialog box.

 

Figure 37

 

17.   Right click on the CA certificate in the right pane of the console and click the Copy command (figure 38).

 

Figure 38

 

18.   Expand the Trusted Root Certification Authorities node and click the Certificates node (figure 39). Right click on the Certificates node and click the Paste command. This pastes the CA certificate into the Trusted Root Certificate Authorities\Certificates store and allows this machine to trust certificates issued by this CA.

 

Figure 39

 

19.   Click the Refresh button refresh the display. You should see the certificate appear in the right pane of the console (figure 40). If you do not see the CA certificate in the right pane of the console, repeat the procedure

 

Figure 40

 

20.   Return to the Personal\Certificates node in the left pane of the console and double click on the Web site certificate. In the Web site certificate’s Certificate dialog box, click on the Certification Path tab (figure 41). Notice that the red “x” no longer appears on the CA certificate. Click OK on the Certificate dialog box.

 

Figure 41

 

21.   Close the mmc console (figure 42). You may want to save this console with the name of certificates and store it in the Administrative Tools menu.

 

Figure 42

 

 

 

 

Run the Outlook Web Access Publishing Wizard and create the HOSTS file entry

 

One of the nice improvements ISA Server Feature Pack 1 adds to any ISA Server 2000 installation is the Outlook Web Access Publishing Wizard. The OWA Publishing Wizard does most of the work required to publish an internal network OWA site. In fact, the OWA Publishing Wizard can configure the Incoming Web Requests listener to use the Web site certificate.

 

Perform the following steps to create the OWA Web Publishing Rule:

 

1.       Open the ISA Management console (figure 43). Expand the Server and Arrays node and then expand your server name. Expand the Publishing node and click on the Web Publishing Rules node. Right click on the Web Publishing Rules node, point to New and click Publish Outlook Web Access Server.

 

Figure 43

 

2.       Type in a name for the rule in the Outlook Web Access Server rule name text box on the Welcome to the Outlook Web Access Publishing Wizard page (figure 44). Click Next.

 

Figure 44

 

3.       On the Name of Published Server page (figure 45), type in the FQDN of the OWA site in the Internal name or IP address of the Outlook Web Access Server. This information is used to forward the incoming request to the internal OWA server. You can use the IP address of the internal server, or the IP address of the external interface of the firewall protecting the internal OWA server if you are using reverse NAT to publish the OWA server.

 

I prefer to use the actual FQDN the external user uses to connect to the site. This also makes the Web Proxy logs easier to interpret. You can create a HOSTS file entry on the ISA Server that resolves this name to the IP address you want the incoming request forwarded to.

 

Put a checkmark in the Use an SSL connection from the ISA Server to the Outlook Web Access Server checkbox. This forces the ISA Server to establish an SSL link between itself and the OWA server. All communications between the ISA Server and the OWA server are protected by SSL.

 

Click Next.

 

Figure 45

 

4.       On the Listeners page (figure 46), enter the URL that the external users will use to connect to the OWA site. Because we are forcing an SSL connection between the external client and the ISA Server, we use the URL https://owa.internal.net.

 

Click Next.

 

Figure 46

 

5.       On the Secure Connection from Client page (figure 47), put a checkmark in the Enable SSL. Client must use SSL to connect to the ISA Server checkbox. Click the Select button.

 

Select the Web site certificate in the Select Certificate dialog box. Click OK.

 

Figure 47

 

6.       The Web site certificate appears in the Certificate frame (figure 48). Click Next.

 

Figure 48

 

7.       Review the settings on the Completing the Outlook Web page and click Finish (figure 49).

 

Figure 49

 

8.       Select the Save the changes and restart the service(s) option on the ISA Server Warning dialog box (figure 50), and click Finish.

 

Figure 50

 

 

 

Review the Settings on the Incoming Web Requests listener and OWA Web Publishing Rule

 

Let’s now examine the changes the OWA Web Publishing Rule Wizard made to the Incoming Web Requests listener and the details of the Web Publishing Rule.

 

Perform the following steps to review the changes to the Incoming Web Requests listener:

 

1.       Open the ISA Management console and expand the Servers and Arrays node (figure 51). Right click on your server name and click the Properties command.

 

Figure 51

 

2.       In the server’s Properties dialog box (figure 52), click on the Incoming Web Requests tab. Notice that the Configure listeners individually per IP address has been selected. This option allows the Incoming Web Requests listener to listen on a specific IP address instead of all addresses bound to the external interface of the ISA Server.

 

The Enable SSL listeners checkbox has been enabled. This allows the Incoming Web Requests listener to accept inbound SSL connection requests. The SSL port is set for TCP port 443.

 

Select the listener entry and click the Edit button.

 

Figure 52

 

3.       The Outlook Web Access Publishing Wizard has configured the listener to use the primary address bound to the external interface on the ISA Server. Integrated authentication is enabled by default. The Use a server certificate to authenticate to web clients option is selected and the OWA Web site’s certificate is bound to the listener.

 

The remote OWA client will use basic authentication to communicate with the ISA Server. Put a checkmark in the Basic with this domain checkbox (figure 53).

 

Figure 53

 

4.       Click Yes on the ISA Server Configuration dialog box warning you that basic credentials are sent in the clear (figure 54).

 

Figure 54

 

5.       Enter the name of your domain in the Domain Name text box on the Select Domain dialog box (figure 55) and click OK.

 

Figure 55

 

6.       Remove the checkmark from the Integrated checkbox. You want the remote OWA clients to use only basic authentication and not even try to negotiate integrated authentication (figure 56). Click OK.

 

Figure 56

 

7.       Select the Save the changes and restart the service(s) option and click OK (figure 57).

 

Figure 57

 

8.       Click OK in the server’s Properties dialog box (figure 58).

 

Figure 58

 

 

The Outlook Web Access Web Publishing Wizard created the Web Publishing Rule allowing the ISA Server to forward incoming requests to owa.internal.net to the OWA server on the internal network. Note the FQDN in the request is critical. This FQDN must match exactly the name on the Web site certificate. The client will not be able to establish an SSL link to the Incoming Web Requests listener if there is a mismatch between the FQDN the client uses to access the OWA server, the FQDN of the server in the Destination Set and the name of the OWA server on the certificate.

 

Let’s look at some of the details of the Web Publishing Rule created by the Wizard and tune it up a bit:

 

1.       In the ISA Management console (figure 59), expand your Servers and Arrays node and expand your server name. Expand the Publishing node and click on the Web Publishing Rules node. Double click on the OWA Web publishing rule you created.

 

Figure 59

 

2.       Click on the Destinations tab (figure 60). Notice that the This rule applies to option is set to Selected destination set. The name of the Destination Set is listed in the Name drop down list. The specific destinations included in this Destination Set are seen in the Destinations included in set list.

 

These destinations include the FQDN of the OWA server and the directories that external users are allowed to access. These path entries are:

 

/exchweb*

/public*

/exchange*

 

The wildcard entry at the end of the path indicates that the external client can access all files and folders under the exchweb, public and exchange folders.

 

Figure 60

 

3.       Click on the Action tab. Notice that the Redirect the request to this internal Web server (name or IP address) option is selected (figure 61). The FQDN of the OWA site is entered into the text box under this option. This FQDN must resolve to an IP address that can accept incoming requests to the OWA site. We will create a HOSTS file entry later that insures that the requests are forwarded correctly.

 

The Send the original host header to the publishing server instead of the actual one (specified above) check is enabled. Do not disable this checkbox.

 

Put a checkmark in the Allow delegation of basic authentication credentials checkbox. This allows the ISA Server to forward the basic authentication credentials to the OWA site on the internal network. This allows only authenticated connections to be made to the OWA site. If the client is not authenticated, no packets are forwarded to the internal site.

 

Figure 61

 

4.       Click on the Bridging tab (figure 62). In the Redirect HTTP requests as frame has the SSL requests (establish a secure channel to the site) option select. This setting will be ignored because all connections must be SSL; no non-SSL connections will be accepted.

 

The SSL requests (establish a new secure channel to this site) option is select in the Redirect SSL requests as) frame. This setting insures that SSL requests are bridged as SSL requests (SSL to SSL bridging). The external client establishes an SSL connection with the ISA Server, then the  ISA Server establishes a new SSL connection with the OWA site on the internal network.

 

Put a checkmark in the Require secure channel (SSL) for published site checkbox. This setting forces the external client to successfully negotiate an SSL connection. If the client cannot negotiate an SSL link, the connection is dropped. Put a checkmark in the Require 128-bit encryption checkbox if you know that all your OWA clients support 128-bit (almost all Microsoft clients now support 128-bit encryption).

 

You do not need to select the Use a certificate to authenticate to the SSL Web server checkbox. This is only required if you want to require the ISA Server to use a client certificate to authenticate to the OWA web site. This feature increases security by forcing the ISA Server to present a client certificate to the OWA server before it can connect to it. We will not cover this procedure in this ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document.

 

Figure 62

 

 

Notice that the Web Publishing Rule uses the name of the OWA server, owa.internal.net, in the redirect. This FQDN must resolve to an IP address that can reach the OWA server.

 

There are two methods you can use so that the ISA Server firewall redirects owa.internal.net to the internal network. You can create a split DNS or you can use a HOSTS file located on the firewall. The HOSTS file is simple to create and you can use it to support your OWA publishing rule while putting your split DNS infrastructure together.

 

Perform the following steps to create the HOSTS file on the ISA Server:

 

  1. Open Windows Explorer and navigate to \WINDOWS\system32\drivers\etc directory and open the hosts file.
  2. In the Open With dialog box, select the Notepad entry and click OK.
  3. The hosts file is opened in Notepad. Put a line at the end of the hosts file that resolves the name in the redirect to the IP address that can reach the OWA server on the internal network. For example, if the firewall in front of the OWA server on the internal network is performing reverse NAT to publish the internal OWA site, and the redirect is owa.internal.net, then you would put in the following entry:

 

10.0.0.2     owa.internal.net

 

Where “10.0.0.2” is the IP address of the OWA server machine on the internal network. Make sure you press ENTER after you put this line into the hosts file so that there is an empty line at the end of the file.

 

  1. Close Notepad and click OK to save the changes made to the file.

 

 

 

Increase Security by Requiring Client Certificate Authentication to the Incoming Web Requests Listener

 

The challenge for credentials the OWA client receives is generated by the OWA site and not the ISA Server firewall. You cannot configure the Incoming Web Requests listener to require authentication and also require authentication from the OWA site. For example, if you require basic authentication to connect to the Incoming Web Requests listener, then you can not require authentication on the OWA directories.

 

However, if you require client certificate authentication with the ISA Server firewall’s incoming Web Request listener, then you can allow the OWA site to request credentials from the OWA client on the external network while also allowing the firewall to authenticate the client using certificate authentication.

 

This greatly enhances the security of your OWA publishing solution because the remote host needs to have both a client certificate to authenticate with the Incoming Web Requests listener and a user name and password to connect to the OWA site. If the client can’t produce a valid certificate to the Incoming Web Requests listener, then the connection is dropped by the firewall.

 

Please refer to ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document Enhance Outlook Web Access Publishing Security with Client Certificate Authentication

for more information on how to require client certificate authentication before allowing connections to the OWA Web Publishing Rule’s Incoming Web Requests listener.

 

 

 

Install the URLScan filter on the ISA Server firewall computer

 

The URLScan filter is an optional component of the ISA Server 2000 Feature Pack 1. This version of URLScan installs directly on the ISA Server 2000 firewall computer. Like the version of URLScan that installs on the Web server, the Feature Pack 1 version of URLScan examines incoming HTTP connections for invalid commands and requests. Validity is determined by the settings in the urlscan.ini file.

 

You can download the ISA Server 2000 Feature Pack 1 version of URLScan from the ISA Server 2000 Feature Pack 1 Web site. Download the isafp1ur.exe file from the site and run the installation program. Follow the onscreen instructions. If you are not familiar with the URLScan tool, review the readme file before installing.

 

Be sure to install URLScan on the ISA Server 2000 firewall using the OWA template. The installation Wizard will ask you to make this decision during the installation process.

 

 

 

Configure the public DNS to resolve the names of the OWA site

 

Correct DNS host name resolution is critical when designing a remote access solution. The ideal DNS configuration allows users who move between the internal and external network to be able to resolve host names to the correct address regardless of where they are currently located.

 

The ideal DNS configuration is the split DNS. A split DNS infrastructure consists of two zones that serve the zone domain and subdomains:

 

 

Internal network hosts who need to resolve names on the internal network queries an internal network zone and receives the internal network IP address of the host they want to connect to. External network hosts query the external network zone and receive a public IP address they can connect to. The destination machine is the same for the external and internal hosts; they just take different routes to arrive to their common destination.

 

For example, your internal network domain to which the Exchange Servers belong to is domain.com. You publish the OWA site to the Internet using ISA Server 2000. The ISA Server uses IP address 131.107.0.1 to listen for incoming requests for the OWA site. The Exchange Server on the internal network has the IP address 10.0.0.3.

 

Your goal is to allow all hosts, regardless of their location, to access the Exchange Server using the FQDN owa.domain.com. You want hosts on the internal network to connect directly to the OWA site using the IP address 10.0.0.3 and remote hosts connecting from the Internet to use IP address 131.107.0.1 to access the OWA site.

 

The solution is to create entries on a publicly available DNS server for the domain.com domain. You can have a third party host your DNS services, or you can host them yourself. Regardless of who hosts these addresses, the DNS resource records for the domain.com domain on this publicly available DNS server contain the public addresses your want users to use to access resources. In the case of the published resources on the Exchange Server, you would create a Host (A) record for owa.domain.com to map to the IP address 131.107.0.1.

 

You then create a second DNS server, this one being on the internal network behind the ISA Server firewall. The internal network DNS server also hosts a zone for the domain.com domain. You create a Host (A) resource record on the internal network DNS server within the domain.com zone for owa.domain.com. The difference is that this time you map these three entries to 10.0.0.3.

 

External network hosts are assigned a DNS server address that allows them to resolve names to public addresses. How these external hosts are assigned an IP address depends on where they are located. You usually have no control over the specific DNS server address that’s assigned to your remote hosts. However, this is not a problem. If you have registered your domain.com with an Internet Registrar and indicated the correct address for the publicly available authoritative DNS server for your domain, then external hosts will have no problems resolving your public addresses correctly.

 

Internal network hosts can be assigned a correct DNS server address using DHCP. When a remote host moves into the internal network, it will receive new IP addressing information, including a DNS server address, from your DHCP server. When the host receives the IP address of your internal DNS server, then it will be able to resolve the names associated with the front-end Exchange Server to its internal address.

 

 

Install CA certificates on the OWA clients

 

You must install the root CA certificate of the certificate authority that assigned the Exchange Server’s services their certificates onto the remote OWA client. There are a number of ways to do this. Please refer to the ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document How to Import the Root CA Certificate into Email Client Certificate Stores