Configuring ISA Server 2000 to Support Outlook 2003 RPC over HTTP

 

Exchange Server 2003 allows Outlook 2003 clients installed on Windows XP Service Pack 1 and above full MAPI client access using the new RPC over HTTP protocol. RPC over HTTP allows the RPC commands required for full Outlook 2003 MAPI client access to wrapped or “encapsulated” in an HTTP header and passed through proxies that allow outbound HTTP.

 

In addition, you can secure RPC over HTTP communications using SSL. The RPC over HTTP protocol solves the problem of remote access to the full suite of Exchange Server 2003 services through firewalls that allow only HTTP and HTTPS (SSL) outbound to the Internet. Another advantage of the RPC over HTTP protocol is that it can leverage the security and functionality provided by the front-end/back-end Exchange Server configuration.

 

Its important to keep in mind that in an ISA Server 2000 remote access environment, the RPC over HTTP solution should be thought of as a “second best” method of remote access for the full Outlook 2003 MAPI client. The preferred method, in terms of high security, is secure Exchange RPC publishing because of the security enforced by the intelligent layer 7 aware ISA Server 2000 RPC filter. The RPC over HTTP publishing mechanism does not leverage the security provided by the ISA Server 2000 Exchange RPC filter and does not protect against illegal commands that may be sent to RPC servers.

 

However, this is not to say that RPC over HTTP publishing is without security. The fact is that the RPC over HTTP connection can be made extremely secure using a wide range of security technologies.  The connection between the remote Outlook 2003 client and the external interface of the ISA Server 2000 firewall is protected by SSL. And because ISA Server is able to perform SSL bridging, the connection between the internal interface of the ISA Server firewall and the front-end Exchange Server is also protected by an SSL link.

 

SSL to SSL bridging allows the ISA Server firewall to inspect the RPC over HTTP packets for illegal commands using URLScan and other security filters. The ISA Server firewall passes the RPC over HTTP messages to the front-end Exchange Server after they have passed a security inspection.

 

You can further enhance the security on the RPC over HTTP connection by requiring a transport mode IPSec connection between the front-end and back-end Exchange Servers. This allows end to end encryption between the Outlook 2003 client and the back end Exchange Server. It is important to insure this type of end to end encryption because the client has an implicit expectation of end to end encryption when it establishes a secure link with the external interface of the ISA Server firewall.

 

You need to carry out the following procedures to create a secure RPC over HTTP publishing solution using ISA Server 2000:

 

 

 

 

Install an Enterprise Certificate Authority

 

The Microsoft enterprise Certificate Authority (CA) allows you to issue certificates to all machines in the Active Directory domain. You can install a Microsoft CA in either standalone or enterprise mode. There are two primary advantages of using an enterprise CA over a standalone CA:

 

 

You will use the Microsoft enterprise CA to install machine certificates on the front end and back end Exchange Servers. These certificates will be used for authentication when you create the IPSec Policy to secure the link 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 detailed information on how to install and configure a Microsoft enterprise CA.

 

 

 

Assign Machine Certificates to the Front End and Back End Exchange Servers

 

You can use the enterprise CA to assign machine certificates to the front-end and back-end Exchange Servers. You can use Group Policy to assign these machine certificates or you can use the Certificates MMC standalone snap-in to assign the certificates.

 

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

Issuing certificates via autoenrollment and Issuing certificates via the MMC snap-in for detailed information on how to issue machine certificates to the front-end and back-end Exchange Servers

 

 

 

Install the Back End Exchange Server

 

There are no special requirements for the back-end Exchange Server in the RPC over HTTP publishing scenario. In the example covered in this ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document, we assume the back-end Exchange Server is a domain controller for the domain that all Exchange Servers belong to. While we realize that it is not best practice, this is the configuration we use on the lab network setup in this document.

 

Please refer to TechNet document Microsoft Exchange 2000 Server Front-End and Back-End Topology for details on specific requirements for front-end and back-end Exchange Servers.

 

 

 

Install the Front End Exchange Server and the RPC over HTTP Service

 

The front-end Exchange Server acts as a “proxy” for RPC messages that are carried via the HTTP protocol. This proxy function allows the front-end Exchange Server to receive the RPC messages contained within the HTTP protocol headers and forward these messages to the back-end Exchange Server.

 

The front-end Exchange Server is a proxy for these messages because the front-end Exchange server is not the endpoint for these messages. The front-end Exchange Server only accepts these messages, removes the HTTP header, and forwards them to the back end Exchange Server. When the back-end sends its replies, the replies are accepted by the front-end Exchange Server that’s acting as a RPC over HTTP proxy. The front-end Exchange Server encloses the RPC reply it received from the back-end Exchange Server in an HTTP header and forwards this reply to the Outlook 2003 client.

 

Install and configure the front-end Exchange Server according to the guidelines in Microsoft Exchange 2000 Server Front-End and Back-End Topology. After the front-end Exchange Server is installed, the next step is to install the RPC over HTTP Proxy networking service.

 

Perform the following steps to install the RPC over HTTP Proxy networking service on the front-end Exchange Server:

 

  1. Click Start, point to Control Panel and click on Add or Remove Programs. In the Add or Remove Programs window, click on the Add/Remove Windows Components button (figure 1).

 

Figure 1

 


  1. In the Windows Components dialog box, click on the Networking Services entry in the Components list and then click the Details button (figure 2).

 

Figure 2

 


  1. In the Networking Services dialog box (figure 3), put a checkmark in the RPC over HTTP Proxy checkbox and click OK.

 

Figure 3

 


  1. Click Next in the Windows Components dialog box, click Next (figure 4).

 

Figure 4

 


  1. An Insert Disk dialog box may appear asked you to insert the Windows CD-ROM (figure 5). Click OK.

 

Figure 5

 


  1. Enter a path to the i386 folder in the Files Needed dialog box (figure 6). Click OK.

 

Figure 6

 


  1. Click Finish on the Completing the Windows Components Wizard page (figure 7).

 

Figure 7

 

Close the Add or Remove Programs window.

 

 

 

Configure the Front End Exchange Server Web Service to Listen on a Single IP Address

 

You should configure the front-end Exchange Server’s Web site to listen on a specific IP address. This helps facilitate the Web or Server Publishing Rules you create on the ISA Server firewall that allow inbound access to the RPC over HTTP service on the front-end Exchange Server.

 

Perform the following steps to configure the front-end Exchange Server to listen on a specific IP address:

 

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

 

Figure 8

 

2.       In the Default Web Site Properties dialog box, click select your IP address from the list of IP addresses in the IP address list (figure 9).

 

Figure 9

 

3.       Click Apply and then click OK in the Default Web Site Properties dialog box and then close the Internet Information Services (IIS) Manager console (figure 10).

 

Figure 10

 

 

 

Request and Install a Web Site Certificate on the Front End Exchange Server

 

The front-end Exchange Server’s Web site requires a certificate so that you can enforce SSL connections between the ISA Server firewall and the front-end Exchange Server. In addition, the front-end Exchange Server’s Web site requires a certificate so that the ISA Server firewall can impersonate the site when external Outlook 2003 clients create an SSL link with the firewall’s external interface.

 

You will then export the Web site certificate after the front-end Exchange Server obtains a certificate. The exported file is copied to the ISA Server firewall and imported into the firewall’s local machine certificate store and bound to the Incoming Web Requests listener.

 

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 a Web site certificate for the front-end server.

 

 

 

Export the Web 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 to the front-end server, 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 all invalid packets. The ISA Server firewall then establishes a second SSL session between its own internal interface and the front-end Exchange Server, re-encrypts the packets, and forwards them to the front-end Exchange server.

 

You can not use SSL to protect the communications between the front-end Exchange Server and the back-end servers. However, you can use IPSec transport mode connections to protect all data moving between the front-end and back-end Exchange Servers. This meets the implicit requirement for an end to end encrypted link.

 

The ISA Server 2000 firewall impersonates the front-end 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 11), expand the Web Sites node and click on the Default Web Site entry. Right click on Default Web Site and click Properties.

 

Figure 11

 

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

 

Figure 12

 

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

 

Figure 13

 

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

 

Figure 14

 

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

 

Figure 15

 

6.       On the Export File Format page (figure 16), 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 16

 

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

 

Figure 17

 

8.       On the File to Export page (figure 18), 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 18

 

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

 

Figure 19

 

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

 

Figure 20

 

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

 

Figure 21

 

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

 

Figure 22

 

 

 

 

Force SSL and Basic Authentication on the RPC Directory

 

The external Outlook 2003 clients will use SSL to connect to the external interface of the ISA Server firewall. The ISA Server firewall uses SSL to protect the connection between the internal interface of the firewall and the front-end Exchange Server’s Web site. The Outlook 2003 client will use basic authentication to authenticate with the ISA Server firewall’s Incoming Web Requests listener and the firewall will forward these basic credentials to the front-end Exchange Server’s Web site.

 

You need to force basic authentication on the front-end Exchange Server’s RPC directory to insure the best performance and compatibility. The user credentials are protected by SSL encryption so you do not need to worry about the clear text credentials being captured by an intruder. In addition, we will force an SSL connection between the firewall and the RPC directory. This presents any host, including the firewall, from using a non-secure connection to the front-end server’s RPC directory.

 

Perform the following steps to force basic authentication and SSL encryption on the front-end Exchange Server’s RPC directory:

 

1.       Click Start, point to Administrative Tools and click on Internet Information Services (IIS) Manager. In the Internet Information Services (IIS) Manager, expand your server name and then expand the Web Sites node. Click the Rpc node in the left pane of the console and right click an empty area in the right pane. Click on the Properties command (figure 23).

 

Figure 23

 

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

 

Figure 24

 

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

 

Figure 25

 

4.       Click the Edit button in the Authentication and access control frame (figure 26).

 

Figure 26

 

5.       In the Authentication Methods dialog box (figure 27), put a checkmark in the Basic authentication (password is sent in clear text) checkbox.

 

Figure 27

 

6.       An IIS Manager dialog box appears informing your that there are risks to using basic authentication. That’s OK because we’re using SSL to protect the credentials and the data. Click Yes (figure 28).

 

Figure 28

 

7.       Remove the checkmarks from the Enable anonymous access and Integrated Windows authentication checkboxes (figure 29). Click OK.

 

Figure 29

 

8.       Click Apply and then click OK in the Rpc Properties dialog box (figure 30).

 

Figure 30

 

9.       Close the Internet Information Services (IIS) Manager (figure 31).

 

Figure 31

 

Close the Internet Information Services (IIS) Manager console.

 

 

 

Configure the Registry Entries on the Front End Exchange Server

 

The front-end Exchange Server that is acting as an RPC over HTTP proxy server needs to know the names of the back-end Exchange Servers and global catalog servers. You will need to navigate to the Registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\RpcProxy and change the value of the Valid Ports entry.

 

The change to the ValidPorts value is entered using the following format:

 

ExchangeServerFQDN:593;ExchangeServerFQDN:1024-65535;GlobalCatalogServerFQDN:593;GlobalCatalogServerFQDN:1024-65535

 

Note:
These entries are entered as a single line in the Registry editor; the edit value dialog box does not wrap line.

 

For example, if the back-end Exchange Server is named beexchange2003.internal.net and the Global Catalog Server is named dc.internal.net, the entries would look like this:

 

beexchange2003.internal.net:593; beexchange2003.internal.net:1024-65535; dc.internal.net:593; dc.internal.net:1024-65535

 

You will use fully qualified domain names in this Registry entry. The internal network DNS infrastructure should already be in place because these machines all belong to an Active Directory domain. The front-end Exchange Server must be able to resolve the FQDNs of the back end Exchange and Global Catalog servers.

 

Note:
You do not need to configure specific ports to be used on the Global Catalog server because the Global Catalog server and the Exchange Servers are ISA Server firewall LAT hosts. LAT hosts have full access to each other and communications between them are not screened by firewall policy. Never put a front-end Exchange Server on a DMZ segment.

 

Perform the following steps to configure the Registry on the front-end Exchange Server:

 

1.       Click Start and then click the Run command. Type regedit in the Open text box and click OK. In the Registry Editor, drill down to the following Registry key:

 

HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\RpcProxy

 

Right click on the ValidPorts value and click Modify (figure 32)

 

Figure 32

 

2.       Enter the information in the Value Data text box for the back-end Exchange Server and the Global Catalog server using the format:

 

ExchangeServerFQDN:593;ExchangeServerFQDN:1024-65535;GlobalCatalogServerFQDN:593;GlobalCatalogServerFQDN:1024-65535

 

Click OK after entering the information.

 

Figure 33

 

Restart the front-end Exchange Server computer.

 

 

 

Configure IPSec Policy to Secure All Communications Between the Front End and Back End Servers (optional)

 

The link between the OWA client and the external interface of the ISA Server firewall is protected by SSL encryption. In addition, the link between the internal interface of the ISA Server firewall and the front-end Exchange Server is protected by SSL encryption. The problem is that the link between the front-end and back-end Exchange Server is not protected by SSL encryption. You can not use SSL between the front-end and back-end Exchange servers.

 

You can solve this problem by applying IPSec Policies to force a secure, encrypted link between the front-end and back-end Exchange servers. The IPSec encrypted link protects messages moving between the front-end and back-end, and provides the end to end encryption the OWA client implicitly expects when it creates the secure link with the external interface of the ISA Server.

 

There are several ways you can implement IPSec Policies. The two most popular methods are to create a Group Policy-based security policy and deploy IPSec Policies via domain group policy. Another method is to use local security policy on the front-end and back-end Exchange servers.

 

There are several ways to enforce authentication between the front-end and back-end Exchange Servers when they establish their IPSec links. In this following example we assume that the front-end and back-end Exchange Servers have received machine certificates from the same CA. We will use certificate authentication as the preferred authentication method in the IPSec Policy.

 

Perform the following steps to create the IPSec transport mode secure connection between the front-end and back-end Exchange Servers:

 

1.       Go to the front-end Exchange Server, click Start, point to Administrative Tools and click on Local Security Settings. In the Local Security Settings console, click on the IP Security Policies on Local Computer node in the left pane of the console. Right click on an empty area in the right pane of the console and click the Create IP Security Policy command (figure 34).

 

Figure 34

 

2.       Click Next on the Welcome to the IP Security Policy Wizard page (figure 35).

 

Figure 35

 

3.       On the IP Security Policy Name page (figure 36), give the policy a name in the Name text box. Enter an optional description for the policy in the Description text box. Click Next.

 

Figure 36

 

4.       On the Requests for Secure Communication page (figure 37), remove the checkmark from the Activate the default response rule checkbox and click Next.

 

Figure 37

 

5.       On the Completing the IP Security Policy Wizard page (figure 38), put a checkmark in the Edit properties checkbox and click Finish.

 

Figure 38

 

6.       The Properties dialog box for the policy appears (figure 39). Keep in mind that a security policy consists of a set of rules. If any of the conditions we set in any of the rules matches a connection, then the settings of the rule are triggered. The only rule included in the policy at this point is the default response rule, but it is not selected and we will not select it. Instead, we will add our own rule. Make sure that there is a checkmark in the Use Add Wizard checkbox and click the Add button.

 

Figure 39

 

7.       Click Next on the Welcome to the Create IP Security Rule Wizard page (figure 40).

 

Figure 40

 

8.       We are creating a transport mode connection between the front-end and back-end Exchange Servers. Therefore, on the Tunnel Endpoint page select the This rule does not specify a tunnel option (figure 41).

 

Figure 41

 

9.       Select the All network connections option on the Network Type page (figure 42). Click Next.

 

Figure 42

 

10.   An IP filter list contains IP addresses, computer names, or network IDs and protocol information. When a connection matches a connection specified in the IP filter list, then a filter action is applied. In this example we will create an IP filter list that contains the source IP address being the back-end Exchange Server and the destination IP address being the front-end Exchange Server. We will also configure the IP filter list to match all protocol connections inbound from the back-end Exchange Server to the front-end Exchange Server.

 

On the IP Filter List page, click the Add button (figure 43). In the IP Filter List dialog box, type a name for the filter list in the Name text box. Type an optional description in the Description text box. To add filters to the list, make sure there is a checkmark in the Use Add Wizard checkbox and click the Add button.

 

Figure 43

 

11.   Click Next on the Welcome to the IP Filter Wizard page (figure 44).

 

Figure 44

 

12.   On the IP Filter Description and Mirrored property page (figure 45), type in a description of the filter in the Description text box. You should enter information about the nature of the filter, such as the source and destination addresses and the protocols. In our example, we have a single front-end and back-end Exchange Server, so we’ll just call it OWA.

 

Put a checkmark in the Mirrored. Match packets with the exact opposite source and destination addresses option. This will allow the trigging of the filter action when packets moving in the opposite direction as specified in the filter as detected by the IPSec Policy Agent.

 

Figure 45

 

13.   On the IP Traffic Source page (figure 46), select the A specific IP Address option in the Source address drop down list. In the IP Address text box, type in the IP address of the back-end Exchange Server. You will have to repeat the step if you have multiple back-end Exchange Servers. Click Next.

 

Figure 46

 

14.   On the IP Traffic Destination page (figure 47), select the My IP Address option from the Destination address drop down list. Click Next.

 

Figure 47

 

15.   On the IP Protocol Type page (figure 48), left the default setting of Any in the Select a protocol type drop down list. We want to match all packets moving between the front-end and back-end Exchange Servers, so we match all protocols with this filter list entry. Click Next.

 

Figure 48

 

16.   Do not put a checkmark in the Edit properties checkbox, then click Finish on the Completing the IP Filter Wizard page (figure 49).

 

Figure 49

 

17.   The IP filter that matches all protocols for communications between the front-end and back-end Exchange Server. You have completed the configuration of the IP filter list that matches the packets moving between the front-end and back-end Exchange Server. Click OK to continue create the rule that secures the connection between the front-end and back-end Exchange Servers.

 

Figure 50

 

18.   On the IP Filter List page (figure 51), select the IP filter list you created in the IP Filter lists box. Click Next.

 

Figure 51

 

19.   On the Filter Action page (figure 52), select the Require Security option from the Filter Actions list.

 

When a packet matches the source and destination, as well as protocol included in the filter list, then a Filter Action is triggered. We are creating a rule that includes a filter list we created that matches all protocol packets between the front-end and back-end Exchange Servers. When packets match these conditions, then the Filter Action is applied. The Require Security filter action will require that all packets moving between the front-end and back-end Exchange Server are security with IPSec encryption.

 

Click Next.

 

Figure 52

 

20.   On the Authentication Method page (figure 53), you can choose from Active Directory default (Kerberos V5 protocol), Use a certificate from this certification authority (CA) and Use this string to protect the key exchange (preshared key) options.

 

You and use the Active Directory default option if the front-end and back-end machines belong to the same domain. You can enhance security by using the Use a certificate from this certification authority (CA) option. The front-end and back-end Exchange Server must have machine certificates from the same CA (or in a more complex environment, trust the CAs that issued each other’s machine certificates).

 

In the current example, we have already deployed machine certificates to both the front-end and back-end Exchange Servers, so select the Use a certificate form this certification authority (CA) and click Browse.

 

Figure 53

 

21.   On the Select Certificate dialog box (figure 54), find the CA certificate for your root CA on the internal network and select it. Then click OK.

 

Figure 54

 

22.   The CA information appears in the text box (figure 55). Click Next.

 

Figure 55

 

23.   Put a checkmark in the Completing the Security Rule Wizard checkbox and click Finish (figure 56).

 

Figure 56

 

24.   Click OK on the New Rule Properties dialog box (figure 57).

 

Figure 57

 

25.   On the Properties dialog box for the policy, click the General tab. You can change the Name and the Description for this rule on this tab (figure 58). You can click the Settings button and change core characteristic of the how key exchange is performed. Click OK.

 

Note:
Details of IPSec negotiation and policy as beyond the scope of this ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document. Please refer to Deploying IPSec on the Microsoft TechNet site.

 

Figure 58

 

26.   You will need to repeat the procedure on the back-end Exchange Servers. The only difference between the policy you created on the front-end Exchange Sever and the back-end Exchange Servers is few settings in the IP Filter. Figure 59 shows the IP Traffic Source page of the IP Filter Wizard. On the back-end Exchange Servers, make sure you use the back-end Exchange Server’s address in the source address text box.

 

Figure 59

 

27.   The Destination address on the back-end Exchange Servers is set for My IP address (figure 60).

 

Figure 60

 

28.   The protocol type on the back-end Exchange Server’s is Any. Again, the same as what we did with the front-end Exchange Servers (figure 61).

 

Figure 61

 

 

29.   After the IPSec Policies are created on the front-end and back-end Exchange Servers, right click on the policy you created to secure communications between the front-end and back-end Exchange Servers and click the Assign command (figure 62).

 

Figure 62

 

30.   When the policy is assigned, you will see a Yes entry in the Policy Assigned column (figure 63).

 

Figure 63

 

31.   You can test the policy by opening a command prompt and typing the command:

 

ping –t w.x.y.z

 

where w.x.y.z is the IP address of another Exchange Server included in the IP filter list. You will see the ping command report that it is negotiating IP Security and then you will see ping replies. You can see details of the IPSec negotiation and packet exchange by using the IP Security Monitor standalone mmc console snap-in (figure 64).

 

Figure 64

 

 

 

Install Windows Server 2003 on the Firewall Computer

 

The computer that will become 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 the 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 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 front-end Exchange server to the ISA Server computer. This certificate is imported into the ISA Server’s machine certificate store and then 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 65).

 

Figure 65

 

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

 

Figure 66

 

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

 

Figure 67

 

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

 

Figure 68

 

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

 

Figure 69

 

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

 

Figure 70

 

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

 

Figure 71

 

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

 

Figure 72

 

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

 

Figure 73

 

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

 

Figure 74

 

11.   On the Password page, type in the password for the file (figure 75). 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 75

 

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

 

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

 

Figure 77

 

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

 

Figure 78

 

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

 

Figure 79

 

16.   Click on the Certification Path tab on the Certificate dialog box (figure 80). You may notice a 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.

 

Note:
If you do not see a red “x” then you do not need to carry out the following steps. The absence of the red “x” indicates that you already have the Root CA certificate in your Trusted Root Certification Authorities certificate store.

 

Figure 80

 

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

 

Figure 81

 

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

 

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

 

Figure 83

 

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

 

Figure 84

 

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

 

Figure 85

 

 

 

Create the Web or Server Publishing Rules on the ISA Server Firewall

 

Now you’re ready to create the publishing rule that allows inbound access to the front-end Exchange server. There are two methods you can use to allow inbound access:

 

 

Server Publishing Rules perform a “reverse NAT” function and merely forward the inbound SSL messages to the front-end Exchange Server. The ISA Server firewall is not able to inspect the contents of the SSL communication when you use Server Publishing Rules because the data is protected within an SSL tunnel.

 

Web Publishing Rules are much more secure. The ISA Server firewall is able to inspect the contents of the SSL stream because of ISA Server’s ability to perform SSL bridging. The ISA Server firewall can apply the rules enforced by the urlscan.ini file, as well enforcing the correct URL and delegating basic authentication, so that the OWA client must authenticate with the firewall before a single packet is passed back to the front-end Exchange Server.

 

I highly recommend that you use Web Publishing Rules to publish the front-end Exchange Server that is acting as an RPC over HTTP proxy computer. However, in some cases, you are forced to use Server Publishing Rules, so we will cover both procedures in this ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document.

 

Let’s look at how to create a Server Publishing Rule to allow inbound access to the front-end Exchange Server. The first step is to confirm that the incoming Web Requests listening is not listening on TCP port 443.

 

Perform the following steps to confirm that the incoming Web Requests listener is not listening on TCP port 443:

 

1.       Open the ISA Management console, expand the Servers and Arrays node and right click on your server name. Click on the Properties command (figure 86)

 

Figure 86

 

2.       On the server Properties dialog box (figure 87), click on the Incoming Web Request tab. Notice that there are two options in the Identification frame:

 

Use the same listener configuration for all IP addresses This setting allows the ISA Server firewall to listen on all IP addresses bound to the external interface and use the same security settings for all inbound requests intercepted by the Incoming Web Requests listener

 

Configure listeners individually per IP address This setting allow you to configure a listener separate. For example, if you have three IP addresses bound to the external interface of the ISA Server firewall, then you can commit a single address to listening for inbound connections to Web sites published via Web publishing Rules.

 

You want to prevent the Incoming Web Requests listener from use TCP port 443. First, you should always configure listeners on a per listener basis. This gives you control over the IP addresses used by listeners. Second, you will need to remove the checkmark from the Enable SSL listeners checkbox.

 

Note:
When you remove the checkmark from the Enable SSL listeners checkbox, none of your listeners will be able to listen on TCP 443. This checkbox represents a global setting and you cannot control it on a per listener basis.

 

Figure 87

 

3.       Click Apply after removing the checkmark. You will be asked to restart the services. All the service to restart automatically (figure 88).

 

Figure 88

 

4.       Click OK in the server Properties dialog box (figure 89).

 

Figure 89

 

Removing the SSL listeners allows the Server Publishing Rule to bind TCP port 443. No two services can use the same IP address and port. This is sometimes referred to as socket contention.

 

Creating a Server Publishing Rule

 

Perform the following steps to create a Server Publishing Rule to allow inbound access to the inbound RPC over HTTP connection:

 

1.       Open the ISA Management console (figure 90) and expand the Servers and Arrays node. Expand your server name and then expand the Publishing node. Right click on the Server Publishing Rules node, point to New and click on Rule.

 

Figure 90

 

2.       Enter a name for the RPC over HTTP Server Publishing Rule in the Server publishing rule name text box on the Welcome to the New Server Publishing Rule Wizard page (figure 91). Click Next.

 

Figure 91

 

3.       Type in the IP address of the front-end Exchange Server in the IP address of internal server text box (figure 92). Click the Browse button and select the IP address on the external interface you want to use in the Server Publishing Rule. Click OK in the New Server Publishing Rule Wizard dialog box.

 

Figure 92

 

4.       Click Next on the Address Mapping page (figure 93).

 

Figure 93

 

5.       On the Protocol Settings page (figure 94), select the HTTPS Server protocol from the Apply the rule to this protocol list. Click Next.

 

Figure 94

 

6.       Select the Any request option on the Client Type page (figure 95). Click Next.

 

Figure 95

 

7.       Review your settings and click Finish on the Complete the New Server Publishing Rule Wizard page (figure 96).

 

Figure 96

 

The Server Publishing Rule will starting working without requiring you to restart the computer or any services.

 

Creating a Web Publishing Rule

 

Web Publishing Rules are a more secure alternative to Server Publishing Rules. They can be a bit more complex to put together than Server Publishing Rules, but your reward is a much higher level of security. Creating a Web Publishing Rule to make your front-end Exchange Server’s HTTP proxy service available can be made a lot easier by leveraging the automation provided by the OWA Web Publishing Wizard. The OWA Web publishing Wizard is a feature provided by ISA Server 2000 Feature Pack 1.

 

The OWA Web Publishing Wizard will do most of the work for you. There are just a couple of tweaks you have to make to optimize the rule for security and customize it to support RPC over HTTP publishing.

 

Perform the following steps to create the Web Publishing Rule that will allow remote access to both your OWA site and RPC over HTTP:

 

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

 

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

 

Figure 98

 

3.       On the Name of Published Server page (figure 99), 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  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 99

 

4.       On the Listeners page (figure 100), 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 100

 

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

 

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

 

Figure 102

 

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

 

Figure 103

 

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

 

Figure 104

 

 

Review the Settings on the Incoming Web Requests Listener and the 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 105). Right click on your server name and click the Properties command.

 

Figure 105

 

2.       In the server’s Properties dialog box (figure 106), 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 106

 

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 only basic authentication when communicating with the ISA Server. Put a checkmark in the Basic with this domain checkbox (figure 107).

 

Figure 107

 

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

 

Figure 108

 

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

 

Figure 109

 

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

 

Figure 110

 

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

 

Figure 111

 

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

 

Figure 112

 

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 113), 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 113

 

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

 

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

 

4.       Click on the Bridging tab (figure 116). 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 116

 

5.       In the ISA Management console, expand the Policy Elements node and click on the Destination Sets node. Right click on the Destination Set created by the OWA Wizard and click the Properties command (figure 117).

 

Figure 117

 

6.       Click the Destinations tab in the Destination Properties dialog box (figure 118). Click Add.

 

Figure 118

 

7.       In the Add/Edit Destination dialog box, select the Destination option and put the FQDN of the OWA/RPC site in the text box (figure 119). In the Path text box, type /rpc*

 

Click OK.

 

Figure 119

 

8.       Click Apply and then click OK in the Destination Set Properties dialog box (figure 120).

 

Figure 120

 

9.       Close the ISA Management console (figure 121).

 

Figure 121

 

Note:
You can remove the OWA related from the Destination Set created by the OWA Publishing Wizard if you do not want to make OWA available to external network hosts. Open the Destination Set created by the Wizard and remove the /exchange*, /exchweb* and /public* entries from the list.

 

Close the ISA Management console.

 

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 on the internal network. 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 performing 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  ISA Server to forward the requests to the correct IP address.

 

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

 

 

 

Install the URLScan Filter on the ISA Server 2000 Firewall Computer (optional)

 

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.

 

You will be asked what version of urlscan.ini you want to use when installing URLScan. Choose the Outlook Web Access version of the file. However, this version of urlscan.ini does not contain all the required settings to allow RPC over HTTP to work properly. You will need to open the urlscan.ini file in the \Program Files\Microsoft ISA Server directory and add the following entries:

 

[RequestLimits]

; The entries in this section impose limits on the length

; of allowed parts of requests reaching the server.

MaxAllowedContentLength=2000000000

MaxUrl=16384

MaxQueryString=4096

 

In addition, you need to add the following verbs to the Allow Verbs:

 

RPC_IN_DATA

RPC_OUT_DATA

 

(thanks go to Jim Harrison for discovering these required settings)

 

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 course of installation.

 

 

 

Warning Regarding Client Certificate Authentication between the ISA Server Firewall and the Front End Exchange Server Web Site

 

You can install a client certificate on the ISA Server firewall and configure the OWA site directories to require a client certificate to authenticate to these directories. This increases the level of security afforded to the OWA publishing scenario. However, if you require client certificate authentication on the \Rpc directory, the connection will fail and the external RPC over HTTP client will not be able to connect to the Exchange Server.

 

If you decide to publish both OWA and RPC over HTTP directories, you can force client certificate authentication on the OWA directories and not require client certificate authentication on the \Rpc directory. 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 more information on how to configure client certificate authentication to the OWA site directories.

 

 

 

Configure the Outlook 2003 Client to use RPC over HTTP

 

You must use Outlook 2003 running on Windows XP Service Pack 1 to connect using the RPC over HTTP connection method. In addition, you must install the hotfix mentioned in Microsoft KB article Outlook 11 Performs Slowly or Stops Responding When Connected to Exchange Server 2003 Through HTTP. Download and install the hotfix before configuring a profile that allows the user to connect to the Exchange Server.

 

It is important to note that you must create the profile while the Outlook 2003 computer is on the internal network, or while the Outlook 2003 computer is on the Internet and can access the Exchange Server using RPC (TCP 135). You will not be able to create a new profile or change an existing profile to use RPC over HTTP if is does not have access to the Exchange Server via RPC (TCP 135).

 

This bears repeating: you will not be able to create a new Outlook profile when the Outlook client is not on the internal network and can access the Exchange Server using RPC via TCP 135. In addition, a user with an existing profile will not be able to alter the existing profile so that it can use RPC over HTTP if that client is not located on the internal network and can access the Exchange Server using TCP 135. The Outlook 2003 profile must be configured to use RPC over HTTP while that machine is connected to the internal network and can access the Exchange Server via TCP port 135.

 

Perform the following steps to create the Outlook 2003 profile:

 

1.       Click Start and then right click on the Outlook 2003 icon in the menu. Click on the Properties command (figure 122).

 

Figure 122

 

2.       Click the Add button in the Mail dialog box (figure 123).

 

Figure 123

 

3.       Type in a name for the profile in the Profile Name text box (figure 124). Click OK.

 

Figure 124

 

4.       Select the Add a new e-mail account option in the This wizard will allowyou to change the e-mail accounts the direction that Outlook uses page (figure 125). Click Next.

 

Figure 125

 

5.       On the Server Type page (figure 126), select the Microsoft Exchange Server option and click Next.

 

Figure 126

 

6.       On the Exchange Server Settings page (figure 127), type in the FQDN of the front-end Exchange Server. This must be the same name used on the Web site certificate you have assigned to the front-end Exchange Server’s Web site. For example, we obtained a Web site certificate for the front-end Exchange Server’s Web site. The Common Name (CN) on the Web site certificate is owa.internal.net. Therefore we enter owa.internal.net in the Microsoft Exchange Server text box.

 

Type a user account name in the User Name text box. Click the Check Name button to confirm that the Outlook 2003 client machine can communicate with the front-end Exchange Server.

 

Put a checkmark in the Use local copy of Mailbox checkbox.

 

Click the More Settings button.

 

Figure 127

 

7.       You can change how Outlook detects the connection state on the General tab of the Microsoft Exchange Server dialog box (figure 128). Do not make any changes here unless you have an explicit reason to do so.

 

Figure 128

 

8.       Click on the Advanced tab (figure 129). Confirm that there is a checkmark in the Use local copy of Mailbox checkbox. The default selection is Download headers followed by full item.

 

Figure 129

 

9.       Click on the Security tab (figure 130). Put a checkmark in the Encrypt information checkbox. I’m not sure this does anything when you use RPC over HTTP, but encryption is a good thing, so we’ll enable this checkbox anyhow.

 

Figure 130

 

10.   Click on the Connection tab (figure 131). Select the Connect using my Local Area Network (LAN) option. Put a checkmark in the Connect to my Exchange mailbox using HTTP, then click the Exchange Proxy Settings button.

 

Figure 131

 

11.   You configure the specifics of the RPC over HTTP session in the Exchange Proxy Settings dialog box (figure 132). Type in the FQDN to your front-end Exchange Server in the Use this URL to connect to my proxy server for Exchange text box. This is same name listed as the Common Name on the Web site certificate.

 

Put a checkmark in the Mutually authenticate the session when connecting with SSL checkbox. Put in the FQDN of the front-end Exchange Server (the same name listed on the Web site certificate) in the Principal name for proxy server text box. Use the format:

 

Msstd:FQDN

 

For example, we use msstd:owa.internal.net for our published front-end Exchange Server because the Common Name on the certificate is owa.internal.net.

 

Put a checkmark in the Connect using HTTP first, then connect using my Local Area Network (LAN). This is an interesting setting, as its unclear what a “LAN” protocol is in contrast to an “HTTP” protocol. I assume it means to use unencapsulated RPC messages, but I can’t say that for sure.

 

In the Use this authentication when connecting to my proxy server for Exchange drop down box, select the Basic Authentication option. This forces you to use SSL, which is OK, because we are using SSL for our links.

 

Click OK on the Exchange Proxy Settings dialog box.

 

Figure 132

 

12.   Click Apply and OK on the Microsoft Exchange Server dialog box (figure 133).

 

Figure 133

 

13.   Click Next on the Exchange Server Settings page (figure 134).

 

Figure 134

 

14.   Click Finish on the Congratulations! Page (figure 135).

 

Figure 135

 

15.   Click OK on the Mail dialog box (figure 136).

 

Figure 136

 

16.   Open Outlook 2003. You will be able to use HTTPS for the connection, as confirm in the Exchange Server Connection Status window (figure 137). You can access the connection status window by right clicking on the Outlook 2003 icon in the system tray and selecting the connection status command right after you start up Outlook 2003.

 

Figure 137