Publishing Outlook Web Access with a Single NIC Caching Only ISA Servers

 

Many organizations already have an existing firewall infrastructure that includes a DMZ where they place bastion host machines. You do not need to remove your existing firewall infrastructure to leverage the high level of layer 7 security provided by an ISA Server machine. You can place a single NIC caching-only ISA Server in the DMZ, between an Internet edge firewall and an internal network firewall and protect inbound OWA connections from end to end using SSL.

 

This configuration works well for organizations that already have a large financial and educational investment in other firewalls but still want to take advantage of the unique layer 7 protection ISA Server 2000 provides for your OWA site publishing. The caching-only ISA Server can perform SSL to SSL bridging.

 

The feature allows the caching-only ISA Server in the DMZ to protect the OWA communications from end to end and allow the ISA Server to inspect these communications moving through the tunnel. No other firewall in ISA Server’s class can provide this level of protection.

 

To make this work, you need to perform the following steps:

 

·         Configure the Internet edge firewall

·         Configure the internal network edge firewall

·         Configure Unihomed Web Proxy server

·         Install Windows Server 2003 on the Web caching server

·         Configure the network interface on the Web caching server

·         Install certificates on the Web Proxy server and Exchange Server

·         Install the ISA Server software in cache mode

·         Configure the Incoming Web Requests listener including binding the SSL certificate to the listener

·         Create the OWA Web Publishing Rule

·         Install URLScan on the Web caching server

·         Secure the Web caching server with TCP/IP Security

·         Run the Security Wizard?

·         Install the CA Certificate on the client

 

The remainder of this ISA Server 2000 Exchange Server 2000/2003 Deployment Kit article covers the details of these procedures.

 

Configure the Internet Edge Firewall

 

The Internet edge firewall is typically a high performance packet filtering device. The firewall at the Internet edge must be able to more packets in and out of the corporate network as close to wire speed as possible. For this reason, the Internet edge firewall should limit its firewall functionality to packet filtering.

 

The procedure for configuring the packet filters on a firewall to allow inbound HTTP and SSL connections to the caching-only ISA Server in the DMZ varies with each firewall. ISA Server firewalls can perform packet stateful packet filtering between its external interface and a DMZ interface.

 

Figure A shows the Filter Type tab on such a packet filter. This packet filter allows inbound access to TCP port 80. The source port of the remote host is set to All ports and the destination port is TCP 80. The direction of the connection is inbound. You do not need to create an explicit packet filter to allow outbound access to all ports so that the reply can be sent; the ISA Server firewall will create a dynamic packet filter to allow the response to the requesting host.

 

Fig A (figure93)

 

Figure B shows the Local Computer tab in the inbound TCP port 80 packet filter. The local computer is the DMZ host computer with the IP address 131.107.0.3.

 

Fig B (fig94)

 

Figure C shows the ISA Server packet filter configuration that allows inbound access for SSL connections. Like the HTTP packet filter, you do not need to create an explicit outbound packet filter that allows the response to all ports on the external clients; the ISA Server firewall will create a dynamic packet filter to allow the response to the requesting host.

 

Fig C (fig95)

 

Figure D shows the Local Computer tab for the SSL packet filter. The local computer is the DMZ host with the IP address 131.107.0.3.

 

FigD (fig96)

 

You can use any firewall at the Internet edge. The examples above demonstrate how you would configure an ISA Server 2000 computer with stateful packet filters to allow inbound access at the highest velocity.

 

 

Configure the Internal Network Edge Firewall

 

The firewall at the internal network edge protects the internal network from attack in the event that a host in the DMZ has been compromised. The OWA server is located behind the internal network firewall. The single NIC caching-only ISA Server forwards requests from external hosts to the OWA site on the internal network. Because the OWA server, even in a front end/back end configuration, must be a member of the user domain, you never put a front end server or back end Exchange Server on a DMZ segment. Only machines designed to be bastion hosts should be placed on a DMZ segment.

 

There are two ways the requests from the caching-only ISA Server can get to the internal network through the internal network firewall:

 

 

The caching-only ISA Server will forward packets to the IP address of the OWA site when the packets are routed. On the other hand, you can publish the OWA site on the internal network by using some form of reverse NAT. An example of publishing the internal OWA site using reverse NAT is an ISA Server SSL Server Publishing Rule. Figure E shows the Action tab of an ISA Server 2000 SSL Server Publishing Rule.

 

When publishing the OWA site using reverse NAT on the internal firewall, the caching-only ISA Server will forward inbound connection requests to the OWA site to the IP address on the external interface of the internal firewall that is listening for the inbound SSL connection requests.

 

Figure E (fig98)

 

 

Configure Unihomed Web Proxy Server

 

You’ re ready to configure the ISA Server to securely publish your OWA site after the internal and external firewalls are configured to allow the HTTP and SSL traffic through from the Internet to the DMZ and to the internal network. You will carry out the following procedures on the machine that will be the Web caching-only ISA Server:

 

 

Let’s go through the details of each of these procedures.

 

 

Install Windows Server 2003 on the Web Caching Server

 

The machine running Windows Server 2003 should meet the following minimum system requirements:

 

Requirement

Standard Edition

Enterprise Edition

Datacenter Edition

Web Edition

Minimum CPU Speed

133 MHz

133 MHz for x86-based computers

733 MHz for Itanium-based computers*

400 MHz for x86-based computers

733 MHz for Itanium-based computers*

133 MHz

Recommended CPU Speed

550 MHz

733 MHz

733 MHz

550 MHz

Minimum RAM

128 MB

128 MB

512 MB

128 MB

Recommended Minimum RAM

256 MB

256 MB

1 GB

256 MB

Maximum RAM

4 GB

32 GB for x86-based computers

512 GB for Itanium-based computers*

64 GB for x86-based computers

512 GB for Itanium-based computers*

2 GB

Multiprocessor Support **

Up to 4

Up to 8

Minimum 8 required

Maximum 64

Up to 2

Disk Space for Setup

1.5 GB

1.5 GB for x86-based computers

2.0 GB for Itanium-based computers*

1.5 GB for x86-based computers

2.0 GB for Itanium-based computers*

1.5 GB

 

The ISA Server Web caching component can be very memory intensive. If you plan to use the ISA for both forward and reverse caching, you may wish to significantly increase the amount of RAM installed on the machine.

 

Please refer to ISA Server performance/scalability whitepaper for more information on creating the optimal configuration for your caching-only ISA Server on the DMZ.

 

 

Configure the Network Interface on the Web Caching Server

 

The Web caching only ISA Server has a single network interface because it does not perform standard firewall functions. However, that is not to say that the Web caching only ISA Server cannot provide security for your OWA clients and server. For example, when you force SSL between the clients and the ISA Server and the ISA Server to the OWA server, the data is protected from end to end.

 

The network interface card is configured with a valid IP address and subnet mask for the DMZ segment. A DNS server address is not required unless you want to use the Web caching ISA Server to perform forward Web Proxy. If you want the Web caching only ISA Sever to perform forward Web caching, you should configure the interface with a DNS server that can resolve Internet DNS host names.

 

If you only want to use the Web caching ISA Server to allow inbound access to the OWA server on the internal network, then you can configure a HOSTS file entry on the Web caching only ISA Server that resolves the name of the OWA server to the appropriate address.

 

The default gateway on the Web caching only ISA Server should be set for the address you’re using for your gateway to the Internet. In this article, we assume that the Internet edge firewall has an interface on the Internet and an interface on the DMZ segment. The Web caching only ISA Server uses Internet edge firewall’s DMZ interface address as its default gateway.

 

Note:
In the example we discuss in this document, the internal network edge firewall is using reverse NAT to publishing the HTTP and SSL ports for the OWA server on the internal network. If you are routing between the DMZ and the internal network, you will need to create an explicit routing table entry on the Web caching only ISA Server that instructs it how to reach the internal network ID.

 

A common error in configuring the Web caching only ISA Server is to install two network interface cards and attempt to configure one card to accept the incoming connection and the second network interface card to forward the incoming OWA requests. This is not required, and it will not work.

 

 

Install Certificates on the Outlook Web Access Server and the Web Caching Only ISA Server

 

In order to support an SSL connection between the ISA Server and the OWA Web site, you must install a Web site certificate on the OWA server and bind that certificate to the OWA Web site. You can use the IIS Web Site Certificate Request Wizard to request a certificate from either an online or offline certificate server. Please refer to ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document How to Obtain a Web Site Certificate (obtainwebcert.doc) for details on how to request the Web site certificate and bind that certificate to the site.

 

The next step is to export the Web site certificate after you bind the Web site certificate to the OWA web site. You then copy the exported certificate (with it’s private key) to the Web caching only ISA Server and bind that certificate to the Incoming Web Requests listener.

 

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 X (fig1)

 

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

 

Figure X (fig2)

 

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

 

Figure 3 (fig3)

 

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

 

Figure 4 (fig4)

 

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

 

Figure 5 (fig5)

 

  1. On the Export File Format page, 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 (fig6)

 

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

 

Figure 7 (fig7)

 

  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 (fig8)

 

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

 

Figure 9 (fig9)

 

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

 

Figure 10 (fig10)

 

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

 

Figure 11 (fig11)

 

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

 

Figure 12 (fig12)

 

Close the Internet Information Services (IIS) Manager console.

 

The next step is to import the Web site certificate into the machine certificate store on the Web caching only ISA Server. You must first import the Web site certificate into the Web caching only ISA Server’s machine certificate before you can bind that certificate to the ISA Server’s 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 13).

 

Figure 13 (fig13)

 

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

 

Figure 14 (fig14)

 

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

 

Figure 15 (fig15)

 

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

 

Figure 16 (fig16)

 

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

 

Figure 17 (fig17)

 

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

 

Figure 18 (fig18)

 

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

 

Figure 19 (fig19)

 

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

 

Figure 20 (fig20)

 

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

 

Figure 21 (fig21)

 

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

 

Figure 22 (fig22)

 

11.   On the Password page, type in the password for the file (figure 23). 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 located in a DMZ 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 23 (fig23)

 

12.   On the Certificate Store page (figure 24), 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 24 (fig24)

 

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

 

Figure 25 (fig25)

 

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

 

Figure 26 (fig26)

 

15.   You will see the Web site certificate an the CA certificate in the right pane of the console. The Web site certificate has the FQDN that is assigned to the Web site. This is the name external users will 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 27).

 

Figure 27 (fig27)

 

16.   Click on the Certification Path tab on the Certificate dialog box (figure 28). 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 28 (fig28)

 

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

 

Figure 29 (fig29)

 

18.   Expand the Trusted Root Certification Authorities node and click the Certificates node (figure 30). 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 30 (fig30)

 

19.   Press F5 to refresh the display. You should see the certificate appear in the right pane of the console (figure 31). If you do not see the CA certificate in the right pane of the console, repeat the procedure

 

Figure 31 (fig31)

 

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 32). Notice that the red “x” no longer appears on the CA certificate. Click OK on the Certificate dialog box.

 

Figure 32 (fig32)

 

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

 

Figure X (fig33)

 

 

 

Install the ISA Server Software in Cache Mode

 

The single NIC caching-only ISA Server does not perform any tradition firewall functions. This ISA Server will proxy connection requests between external clients and the OWA site on the internal network. This caching-only ISA Server does provide security for the connections using SSL to SSL bridging. The connection between the client and the ISA Server is protected by SSL encryption, and the connection between the ISA Server and the OWA site is protected by SSL.

 

To install ISA Server 2000 in Cache only mode on a Windows Server 2003 Server, you need to perform the following procedures:

 

 

The instructions for installing ISA Serve 2000 Service Pack 1, ISA Server hotfix isahf255.exe and ISA Server 2000 Feature Pack 1 are in ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document Installing ISA Server 2000 on Windows Server 2003. Install the service pack, the hotfix and the feature pack after you have installed the ISA Server 2000 software on the Windows Server 2003 machine.

 

Perform the following steps to install ISA Server 2000 in Cache only mode:

 

1.       Double click on the isaautorun.exe file. Click the Install ISA Server entry on the Microsoft ISA Server Setup page (figure 34).

 

Figure 34 (fig34)

 

2.       An ISA 2000 warning dialog box appears informing you that ISA Server 2000 Service Pack 1 must be installed on the machine. Click Continue (figure 35).

 

Figure 35 (fig35)

 

3.       Click Continue on the Welcome to the Microsoft ISA Server installation program page (figure 36).

 

Figure 36 (fig36)

 

4.       Enter your CD key on the CD Key page (figure 37) and click OK.

 

Figure 37 (fig37)

 

5.       Write down your product ID on the Product ID page (figure 38). Click OK.

 

Figure 38 (fig38)

 

 

6.       Read the information  on the EULA page and click I Agree (figure 39).

 

Figure 39 (fig39)

 

7.       Click the Full Installation button on the installation page (figure 40).

 

Figure 40 (fig40)

 

8.       Click Yes on the dialog box that informs you that the installation program cannot find the ISA Server 2000 Active Directory objects (figure 41).

 

Figure 41 (fig41)

 

9.       On the ISA Server 2000 Mode type page, select the Cache mode option (figure 42).

 

Figure 42 (fig42)

 

10.   On the Cache Drives page (figure 43), select an NTFS formatted drive in the Drive list. Type in the size of the cache in the Cache size (MB) text box and click Set.

 

If you are using this caching-only ISA Server only as a proxy for incoming OWA requests, you do not need to change the size of the cache file. However, if you want to use this machine as an outbound Web proxy for internal network clients, you should increase the size of the cache based on the recommendations contained in ISA Server Performance Best Practices.

 

Click OK.

 

Figure 43 (fig43)

 

11.   Click OK on the Setup Message dialog box that informs you that the Message Screener requires the SMTP service. This machine will not screen SMTP messages.

 

Figure 44 (fig44)

 

12.   Remove the checkmark from the Start ISA Server Getting Started Wizard dialog box and click OK (figure 45). Notice the information balloon informing you Devices or applications disabled. This is normal. Click the close button on the balloon to dismiss it.

 

Figure 45 (fig45)

 

13.   Click OK on the Microsoft ISA Server Setup dialog box informing that the software was installed successfully (figure 46).

 

Figure 46 (fig46)

 

14.   Click OK in the Setup Warning dialog box informing you that one or more services failed to start (figure 47).

 

Figure 47 (fig47)

 

You must immediately install ISA Server 2000 Service Pack 1. The machine will restart after you install ISA Server 2000 Service Pack 1. Then install ISA Server 2000 hotfix 255 and ISA Server 2000 Feature Pack 1.

 

 

Configure the Incoming Web Requests Listener and Bind the SSL Certificate to the Listener

 

The caching-only ISA Server uses SSL to secure the connection between the external network client and the ISA Server’s Web Proxy service. The Web Proxy service uses the Web site certificate to create the SSL link. You must bind the Web site certificate to the Incoming Web Requests listener before the Web Proxy service can use the certificate to secure the incoming connections. This allows the caching-only ISA Server to impersonate the OWA Web site.

 

Perform the following steps to bind the Web site certificate to the Incoming Web Requests listener:

 

1.       At the caching-only ISA Server machine, open the ISA Management console and expand the Server and Arrays node. Right click on your server name and click the Properties command (figure 48)

 

Figure 48 (fig48)

 

2.       Click on the Incoming Web Request tab in the server’s Properties dialog box (figure 49). Select the Configure listener individually per IP address option and click the Add button.

 

Figure 49 (fig49)

 

3.       In the Add/Edit Listeners dialog box (figure 50), select your server in the Server drop down list box. Select the IP address that resolves to the name of the OWA site (as configured in your public DNS) in the IP Address list.

 

By default, the Integrated option is selected. You may want to remove this option to improve performance.

 

Put a checkmark in the Basic with this domain checkbox.

 

Figure 50 (fig50)

 

4.       Click Yes in the dialog box that warns you that basic credentials are passed “in the clear” and that you should use SSL to protect the user name and password (figure 51). We will configure the caching-only ISA Server to force SSL on client connections to the OWA site.

 

Figure 51 (fig51)

 

5.       In the Select Domain dialog box, type in a default domain name in the Domain Name dialog box (figure 52). The caching-only ISA Server is not a member of a domain, so you need to enter your user domain in this text box if you want the users to be able to enter just their user name and password. Otherwise, the users will need to enter the domain name when they log onto the OWA site. Click OK.

 

Note:
I highly recommend that you allow only basic authentication to be used with the Incoming Web Requests listener. This will significantly improve log on performance and does not represent a security risk because credentials and data will always be protected in an SSL tunnel.

 

Figure 52 (fig52)

 

6.       On the Add/Edit Listeners dialog box (figure 53), notice that you can enable Digest with this domain, Integrated and Client certificate (secure channel only) authentication. Enable only basic authentication for best performance. For the highest level of security, use client certificate authentication only.

 

Click OK.

 

Figure 53 (fig53)

 

7.       The next step is to bind the Web site certificate to the Incoming Web Request listener. Put a checkmark in the Use a server certificate to authenticate to web clients checkbox and click Select.

 

In the Select Certificate dialog box (figure 54), click on the OWA Web site certificate and click OK.

 

Figure 54 (fig54)

 

8.       Click OK in the Add/Edit Listeners dialog box (figure 55).

 

Figure 55 (fig55)

 

9.       On the Incoming Web Request tab, put a checkmark in the Enable SSL listeners checkbox (figure 56). Click OK on the SSL Listeners dialog box informing you that you must bind a certificate to the listener to accept incoming SSL connections.

 

Note:

Only one certificate can be bound per listener. If you want to host multiple OWA servers, with each OWA server accessible from a different FQDN, then you must bind multiple IP addresses to the caching-only ISA Server and create a listener for each SSL protected site and bind the site’s certificate to the listener for that site.

 

Figure 56 (fig56)

 

10.   On the ISA Server Warning dialog box (figure 57), select the Save the changes and restart the service(s) option and click OK.

 

Figure 57 (fig57)

 

 

The Web Proxy service will restart. At this point the listener will be able to support secure authenticated connections on the IP address you configured for the listener. However, the listener must pass an incoming request to a Web Publishing Rule. The next step is to create the OWA Web Publishing Rule so that the Web Proxy service knows how to forward the incoming requests from Web browsers seeking to be OWA clients.

 

 

Create the OWA Web Publishing Rule

 

One of the very nice improvements ISA Server Feature Pack 1 adds is the Outlook Web Access Publishing Wizard. The OWA Publishing Wizard does most of the work required to publish an OWA site on the internal network. In fact, the OWA Publishing Wizard can configure the Incoming Web Requests listener to use the Web site certificate. We went through that process manually so that you have a better idea of how it works, which will aid in troubleshooting SSL related problems if they occur.

 

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

 

1.       Open the ISA Management console (figure 58). 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 58 (fig58)

 

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 59). Click Next.

 

Figure 59 (fig59)

 

3.       On the Name of Published Server page (figure 60), 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 that the external user uses to connect to the site. This makes the Web Proxy logs easier to interpret. You can create a HOSTS file entry on the caching-only 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 caching-only ISA Server to establish an SSL link between itself and the OWA server. All communications between the caching-only ISA Server and the OWA server are protected by SSL.

 

Click Next.

 

Figure 60 (fig60)

 

 

4.       On the Listeners page (figure 61), 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 caching-only ISA Server, we use the URL https://owa.internal.net.

 

Click Next.

 

Figure 61 (fig61)

 

 

5.       On the Secure Connection from Client page (figure 62), 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 62 (fig62)

 

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

 

Figure 63 (fig63)

 

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

 

Figure 64 (fig64)

 

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

 

Figure 65 (fig65)

 

 

The Outlook Web Access Web Publishing Wizard created the Web Publishing Rule that allows the ISA Server to forward the incoming requests to owa.internal.net to the OWA server on the internal network. Note that 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 66), 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 66 (fig66)

 

2.       Click on the Destinations tab (figure 67). 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 67 (fig67)

 

3.       Click on the Action tab. Notice that the Redict the rquest to this internal Web server (name or IP address) option is selected (figure 68). 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 caching-only 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 68 (fig68)

 

4.       Click on the Bridging tab (figure 69). 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 caching-only ISA Server, then the caching-only 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 caching-only ISA Server to use a client certificate to authenticate to the OWA web site. This feature increases security by forcing the caching-only 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 69 (fig69)

 

 

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. If you are routing between the DMZ and the internal network, the FQDN must resolve to the actual IP address of the OWA server. If you are performed reverse NAT between the OWA server and the DMZ (such as a Server Publishing Rule in ISA Server 2000), then the FQDN must resolve to the address of the external interface of the firewall on the edge of the private network.

 

You can configure a DNS server to support DMZ hosts, or you can use a HOSTS file on the Web caching only ISA Server to forward the requests to the correct IP address.

 

Perform the following steps to create the HOSTS file on the caching-only 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:

 

131.107.0.2              owa.internal.net

 

Where “131.107.0.2” is the IP address on the external interface of the internal network firewall that is publishing the internal network OWA site, and owa.internal.net is the entry in the Web Publishing Rule for the redirection. 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.

 

 

Secure the Web Caching Server with TCP/IP Security

 

The caching-only ISA Server is a bastion host on a DMZ segment and therefore is open to attack by Internet intruders. One method you can use to protect the caching-only ISA Server is to restrict the ports that the machine will accept inbound connections on. You should allow only SSL connection requests to the caching-only ISA Server that is publishing the internal OWA site. TCP/IP Security filters can be used to block all incoming TCP and UDP connections except for TCP port 443 (SSL).

 

Note:

You will not be able to remotely manage this machine if you allow only inbound SSL connections. If you want to allow incoming RDP (Remote Desktop Protocol) connections for remote management, you can create a second filter that allows inbound TCP 3389 (RDP). Note that you cannot using TCP/IP Security filtering to block ICMP packets.

 

Perform the following steps to secure the caching-only ISA Server using TCP/IP Security filtering:

 

1.       Right click on the My Network Places icon on the desktop (figure 70) and click Properties.

 

Figure 70 (fig70)

 

2.       Right click on the network interface entry in the Network Connections window and click Properties (figure 71).

 

Figure 71 (fig71)

 

3.       In the connection’s Properties dialog box (figure 72), select the Internet Protocol (TCP/IP) entry and click the Properties button.

 

Figure 72 (fig72)

 

4.       Click the Advanced button in the Internet Protocol (TCP/IP) Properties dialog box (figure 73).

 

Figure 73 (fig73)

 

5.       On the Advanced TCP/IP Settings dialog box (figure 74), click on the TCP/IP Filtering entry in the Optional settings list and click Properties.

 

Figure 74 (fig74)

 

6.       In the TCP/IP Filtering dialog box (figure 75), Put a checkmark in the Enable TCP/IP Filtering (All adapters) checkbox. Select the Permit Only option in the TCP Ports, UDP Ports and IP Protocols lists.

 

Click the Add button under the TCP Ports list. In the Add Filter dialog box, type 443 in the TCP Port text box and click OK.

 

Figure 75 (fig75)

 

7.       Port 443 appears in the TCP Ports list (figure 76). Click OK.

 

Figure 76 (fig76)

 

8.       Click OK in the Advanced TCP/IP Settings dialog box (figure 77).

 

Figure 77 (fig77)

 

9.       Click OK in the Internet Protocol (TCP/IP) Properties dialog box (figure 78).

 

Figure 78 (fig78)

 

10.   Close Close in the interface’s Properties dialog box (figure 79).

 

Figure 79 (fig79)

 

11.   Click Yes on the Local Network dialog box to restart the caching-only ISA Server.

 

Figure 80 (fig80)

 

 

Install URLScan on the Web caching server

 

ISA Server 2000 Feature Pack 1 includes a special version of URLScan that you can run on the ISA Server computer. URLScan protects all Web Servers you publish via the ISA Server computer using the settings in the urlscan.ini file on the ISA Server computer. When using the single interface caching-only ISA Server to publish your OWA site, you can use a pre-configured urlscan.ini file to protect your OWA web site.

 

Note:

The same urlscan.ini file settings are applied to all Web sites published via the ISA Server computer. You cannot create custom urlscan.ini settings on a per Web Publishing Rule basis.

 

Perform the following steps to install and configure the ISA Server version of URLScan:

 

1.       Go to the ISA Server Feature Pack 1 Web site and download the isafp1ur.exe file from a machine that is not the ISA Server. Scan the file to confirm that it is safe, and then copy it to the caching-only ISA Server. Double click the isafp1ur.exe file and enter a local path in the Choose Directory For Extracted File dialog box (figure 81) and click OK.

 

Figure 81 (fig81)

 

2.       Read the EULA on the URLScan Web filter for ISA Server Feature Pack 1 dialog box and click I Agree (figure 82).

 

Figure 82 (fig82)

 

3.       Click Yes on the Microsoft ISA Server 2000 Update Setup dialog box that warns you that some Web sites may be inaccessible to users. If you are not conversant with the URLScan utility, then refer to the ISA Server 2000 URLScan readme before installing it.

 

Figure 83 (fig83)

 

4.       Click Yes on the Microsoft ISA Server 2000 Update Setup dialog box that asks if you want to use the urlscan.ini file that has been customized to support OWA site publishing (figure 85).

 

Figure 85 (fig84)

 

5.       The installation routine updates the ISA Server configuration (figure 86).

 

Figure 86 (fig85)

 

6.       Remove the checkmark from the Read about the URLScan Web Filter (figure 86) in the Microsoft ISA Server 2000 Update dialog box and click OK.

 

Figure 86 (fig86)

 

7.       Open the ISA Management console and expand the Extensions node (figure 87). Click on the Web Filters node. The URLScan Filter appears with a green up pointing arrow on its icon. The green arrow indicates that the filter is enabled.

 

Figure 87 (fig87)

 

URLScan is now protecting your published OWA Web site.

 

 

 

Run the Security Wizard

 

ISA Server 2000 includes a security Wizard that will apply Windows 2000 security template settings to the ISA Server computer. These security templates have variable results on the functionality of an ISA Server computer. However, you can safely run the high security template on your caching-only ISA Server that provides inbound access to your OWA site.

 

The security template will harden the caching-only ISA Server that acts as a bastion host on the DMZ. This server hardening makes it more difficult to Internet intruders to successfully attack or disable the caching-only ISA Server machine.

 

Perform the following steps to harden the caching-only ISA Server machine:

 

1.       Open the ISA Management console and expand the Servers and Arrays node. Expand the server name and click on the Computer node (figure 88). Right click on your server name in the right pane of the console and click the Properties command.

 

Figure X (fig88)

 

2.       Read the warning information on the Welcome to the ISA Server Security Configuration Wizard page and click Next.

 

Figure X (fig89)

 

3.       On the Select System Security Level page (figure 90), select the Dedicated option. Click Next.

 

Figure X (fig90)

 

4.       Click Finish on the Congratulations page (figure 91).

 

Figure X (fig91)

 

5.       The ISA Server Security Configuration wizard applies the security settings in the security template (figure 92).

 

Figure X (fig92)

 

6.       You will see an error dialog box when the security configuration Wizard finishes (figure 97). You can open the Securewiz.log file in the ISA Server program folder to see what settings were not successfully applied. This error dialog box does not indicate that no security settings were applied; it just indicates that some security settings where not applied. The server has been successfully hardened compared to its pre-hardened state.

 

Figure X (fig97)

 

 

Install the CA Certificate on the OWA Client Computer

 

The CA certificate of the Certificate Server that issued the Web site certificate must be placed in the OWA client computer’s Trusted Root Certification Authorities machine store. The simplest way to accomplish this is to use a commercial Certificate Authority that already has its Root CA certificate included in the Windows clients’ certificate store.

 

If you are hosting your own CA, you can have your clients connect to the Certificate Server’s Web enrollment site. When the OWA client visits the Web enrollment site, click the Download a CA certificate, certificate chain or CRL link on the Home page of the Web enrollment site.

 

Please see ISA Server 2000 Exchange Server 2000/2003 Deployment Kit documents Issuing certificates via the enterprise CA Web enrollment site and Issuing certificates via the standalone CA Web enrollment site.