ISA Firewall Publishing OWA and RPC/HTTP with a Single IP Address: Part 4 – Single Exchange Server with Separate DC Scenario/LDAP Authentication

If you missed the other articles, check them out at:

In the first three parts of this article series we introduced the network configuration, deployed a simple PKI, and created the OWA and RPC/HTTP Web Publishing Rule.

In this, part 4 of the series, we’ll look at how to configure the Outlook RPC/HTTP client to connect to the Exchange Server using RPC/HTTP. Then we’ll test the configuration to make sure that everything is working as we expect.

Discuss this article

Configure the Outlook Client

I’ve found that on many occasions the ISA Firewall administrator has correctly configured the ISA Firewall’s Web Publishing Rule to support OWA and RPC/HTTP connections, but failed to correctly configure the Outlook RPC/HTTP client. The first thing that you should make sure of is that you’re using the latest version of Outlook 2003 or 2007, and that all security and feature updates have been applied to Outlook (Office Updates). Also, remember that RPC/HTTP only works with Windows XP SP1 and above. I will assume that you are using Windows XP SP2 since SP1 support is near end of life.

In a large production environment, you would use the Office Resource Kit (ORK) tools to deploy the Outlook client configuration, which would include the RPC/HTTP configuration. For more information on using ORK to configure the RPC/HTTP client, please refer to Whitepaper: Configuring Outlook Profiles by Using a PRF File.

In smaller environments it’s a realistic expectation to provide your users detailed instructions on how to configure their Outlook client themselves. In fact, you’re welcome to use this section of the paper and customize it to provide your users detailed and graphical information on how to configure their Outlook RPC/HTTP clients themselves. In this lab we’ll manually configure the Outlook 2003 RPC/HTTP client.

Perform the following steps to configure the Outlook 2003 client:

  1. Click the Start button and right click the E-mail icon (Microsoft Office Outlook) and click the Properties command.


Figure 1

  1. In the Mail Setup dialog box, click the Show Profiles button.


Figure 2

  1. In the Mail dialog box, click the Add button.


Figure 3

  1. In the New Profile dialog box, enter a name for the profile. In this example, we’ll name the new profile AdminTest. Click OK.


Figure 4

  1. On the E-mail Accounts page, select the Add a new e-mail account option and click Next.


Figure 5

  1. On the Server Type page, select the Microsoft Exchange Server option and click Next.


Figure 6

  1. On the Exchange Server Settings page, enter the actual fully qualified domain name for the Exchange Server in the Microsoft Exchange Server text box. Note that this name does not need to be resolvable from the Internet. You do not need to include this name in your public DNS for RPC/HTTP publishing. There has been some confusion in the past because this name did need to be resolvable from the Internet for Secure Exchange RPC Publishing (which does not use HTTP encapsulation for RPC MAPI communications).

    Enter a user name in the User Name text box. In this example we’ll use the default Administrator account. I probably should have created a regular user account, and will do so later, but the administrator account is good enough for us right now to demonstrate OWA and RPC/HTTP access.

    Click the More Settings button.




Figure 7

  1. A Microsoft Office Outlook dialog box appears telling you that the Exchange Server is not available. That’s fine, we don’t need it to be available yet. Click OK to dismiss the dialog box.


Figure 8

  1. The Microsoft Exchange Server dialog box appears. We don’t need to do anything here, so click OK to make it go away.


Figure 9

  1. Another Microsoft Exchange Server dialog box will appear. This time, click the Connection tab. On the Connection tab, put a checkmark in the Connect to my Exchange mailbox using HTTP checkbox. Next, click the Exchange Proxy Settings button.


Figure 10

  1. In the Exchange Proxy Settings dialog box there are many settings we need to address. First, there is the text box under the Use this URL to connect to my proxy server for Exchange. In this text box you must enter the common/subject name of the Web site certificate that you bound to the Web Listener. In addition, this name must also be resolvable to the external interface of the ISA Firewall (or the public address of a device that is forwarding the connection to the ISA Firewall’s external interface). This is the name that external clients must be able to resolve in order to connect to the RPC/HTTP site.

    In this example, the common/subject name on the Web site certificate bound to the Web Listener for the OWA and RPC/HTTP Web Publishing Rule is owa.msfirewall.org, so we’ll enter that name into the Use this URL to connect to my proxy server for Exchange text box.

    The Connect using SSL only checkbox should be enabled by default; if not, make sure it is enabled. Put a checkmark in the Mutually authenticate the session when connecting with SSL checkbox. In the Principle name for proxy server text box, enter the common/subject name on the Web site certificate bound to the Web Listener that’s listening for the incoming RPC/HTTP connections prefaced by msstd:  In this example, we enter msstd:owa.msfirewall.org.

    By default, the On fast networks, connect using HTTP first, then connect using TCP/IP is disabled, and On slow networks, connect using HTTP first, then connect using TCP/IP is enabled. These are good default settings, but in order to see how things work in our demo environment, we need to put a checkmark in the On fast networks, connect using HTTP first, then connect using TCP/IP checkbox so that the client will use RPC/HTTP on our fast network connection.

    The last option is the authentication settings. From the Use this authentication when connecting to my proxy server for Exchange drop down list, select the Basic Authentication option. We must use this option because the ISA Firewall’s Web listener is configured to use Forms-based authentication and will fall back to Basic authentication for non-Web browser clients, like the Outlook RPC/HTTP client. The primary drawback of Basic authentication is that users must enter their credentials each time they open Outlook. This is the trade off you make when you have only a single IP address bound to the external interface of the ISA Firewall.

    Click OK in the Exchange Proxy Settings dialog box.










Figure 11

  1. Click OK in the Microsoft Exchange Server dialog box.


Figure 12

  1. Click Next on the Exchange Server Settings page.


Figure 13

  1. Click Finish on the Congratulations! page.


Figure 14

  1. In the Mail dialog box, make sure that the Prompt for a profile to be used option is selected so that if there is more than one profile on this computer, you can choose the AdminTest profile for our demo.


Figure 15

Discuss this article

Installing the CA Certificate on the Outlook RPC/HTTP Client Machine

When you use a Web browser to connect to secure SSL Web sites, you might encounter a dialog box that informs you that your computer does not trust the certificate presented by the Web server. You have the option at that point of either continuing to connect to the Web server, or stop the connection.

What determines whether or not your machine trusts the certificate presented by the Web site is the presence of the CA certificate that signed the Web site’s certificate in the client machine’s Trusted Root Certification Authorities machine certificate store. If that CA certificate is missing from the Trust Root Certification Authorities machine certificate store, then the client computer won’t trust the Web site certificate.

While we have the option of continuing with the connection when using a Web browser, we don’t have that option when connecting using the Outlook RPC/HTTP client. If the client computer does not trust the certificate presented to it by the ISA Firewall computer, then the connection fails and does not provide you any information on why the connection failed. The solution to this problem is to place the CA certificate of issuing CA into the client’s Trusted Root Certification Authorities machine certificate store.

The easiest way to install the CA certificate on the client machines is to install an enterprise CA in your organization and then make the client computer a domain member. This will automatically place the enterprise CA certificate into the clients’ Trusted Root Certification Authorities machine certificate store.

However, if you have machines that are not domain members that you want to be RPC/HTTP clients, you need to manually install the CA certificate. There are many ways you can do this, such as having the clients go to the Web enrollment site or distributing the CA certificate file to users and have them install them manually. In the following example, the RPC/HTTP client machine is not a domain member, so we’ll manually import the CA certificate.

Perform the following steps to install the CA certificate into the Outlook RPC/HTTP client:

  1. Go to the domain controller machine (dc.msfirewall.org), open Windows Explorer, and look at the root of the C: drive. There you will see the CA certificate of this enterprise CA. Copy this file to removable media or find some other mechanism to copy it to the client machine.
  2. Click Start and then click the Run command. Enter mmc into the Open text box and click OK.
  3. In the Console1 window, click File and then click Add/Remove snap-in
  4. In the Add/Remove Snap-in dialog box, click Add
  5. In the Add Standalone Snap-in dialog box, click the Certificates entry and click Add.
  6. On the Certificates snap-in page, select the Computer account option and click Next.
  7. On the Select Computer page, select the Local computer option and click Finish.
  8. Click Close in the Add Standalone Snap-in dialog box.
  9. Click OK in the Add/Remove Snap-in dialog box.
  10. In the left pane of the console, expand the Trusted Root Certification Authorities node and right click the Certificates node. Point to All Tasks and click Import.


Figure 16

  1. Click Next on the Welcome to the Certificate Import Wizard page.
  2. On the File to Import page, click the Browse button and locate the CA certificate file. Click on the file and click Open.


Figure 17

  1. Click Next on the File to Import page.
  2. On the Certificate Store page, accept the default settings and click Next.
  3. Click Finish on the Completing the Certificate Import Wizard page.
  4. Click OK in the dialog box informing you that the import was successful.
  5. The CA certificate will appear in the list of CA certificates.


Figure 18

Test the Configuration

Now we’re ready to test the configuration. Begin by opening Outlook 2003. You’ll see the Choose Profile dialog box as seen below. Select the AdminTest profile from the drop down list and click OK.


Figure 19

The log on dialog box appears. Enter the user name and password for the account. In this example, we’re using the default Administrator account in the msfirewall.org domain. Click OK.


Figure 20

Since this is the first time Outlook is being used on the client machine, you’ll see the Preparing Outlook for first use dialog box. After that the Outlook application opens and displays the user’s mailbox.


Figure 21

Hold down the CTRL key on the keyboard and right click the Outlook icon in the System Tray. Click the Connection Status command. You’ll see the Exchange Server Connection Status window. You can see in the Conn column that the HTTP/RPC protocol is being used.


Figure 22

Now let’s test the OWA connection. In Internet Explorer, enter https://owa.msfirewall.org/exchange in the address bar and press ENTER. You’ll see the ISA Firewall generated form. Select the This is a private computer option and enter the user name and password. Since we’re using basic authentication, you will need to enter the user name as msfirewall\administrator. Click the Log on button.


Figure 23

The OWA site opens up!


Figure 24

Discuss this article

Summary

So far, so good. We were able to publish both the OWA and RPC/HTTP sites using a single IP address. This is something we could never do with ISA 2004. But there’s a lot more we can do with the new ISA Firewall. In the next part of this series we’ll take a look at how you can use LDAP authentication to leverage Active Directory security groups and limit access so that only users who are members of those groups can get past the ISA Firewall and to the published Exchange Server. We’ll also take a look at how you automatically redirect users who forget to enter https:// and /exchange in the address path.

If you missed the other articles, check them out at:

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top