Configuring ISA Server 2000 to Support Outlook 2003 RPC over HTTP – Part 4: Reviewing and Customizing the Web Publishing Rule

Configuring ISA Server 2000 to Support Outlook 2003 RPC over HTTP
Part 4: Reviewing and Customizing the Web Publishing Rule


By Thomas W Shinder M.D.

Part 1 of this series can be found at:


http://www.msexchange.org/articles/rpchttppart1.html

Part 2 of this series can be found at:


http://isaserver.org/articles/rpchttppart2.html

Part 3 of this series can be found at:


http://www.isaserver.org/tutorials/rpchttppart3.html

In part 3 in our series on RPC over HTTP publishing, we began by discussing the Windows Server 2003 and ISA Server 2000 installation procedures. We then imported the Web site certificate into the ISA Server 2000 firewall’s machine certificate store. We ended up part three of this series by creating the an OWA publishing rule, which we’ll modify to support RPC over HTTP publishing.

In this, part 4 and the final article in the series regarding how to configure the firewall and network infrastructure to support inbound RPC over HTTP connections, we’ll cover the following topics:

  • Review the settings on the Incoming Web Requests listener
  • Install the URLScan filter on the ISA Server 2000 machine
  • Warning regarding client certificate authentication
  • Note that I won’t be covering configuration of the Outlook 2003 client in this series. I’ll publish a separate article on the Outlook 2003 client configuration.

    Get the Book!

    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. Right click on your server name and click the Properties command.
    2. In the server’s Properties dialog box, 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.

    1. 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 client will use only basic authentication when communicating with the ISA Server. Put a checkmark in the Basic with this domain checkbox.

    1. Click Yes on the ISA Server Configuration dialog box warning you that basic credentials are sent in the clear.
    2. Enter the name of your domain in the Domain Name text box on the Select Domain dialog box and click OK.

    1. Remove the checkmark from the Integrated checkbox. You want the remote clients to use only basic authentication and not try to negotiate integrated authentication. Click OK.

    1. Select the Save the changes and restart the service(s) option and click OK.
    2. Click OK in the server’s Properties dialog box.

    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, 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.
    2. Click on the Destinations tab. 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.

    1. Click on the Action tab. Notice that the Redirect the request to this internal Web server (name or IP address) option is selected. 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.

    1. Click on the Bridging tab. 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 article.

    1. 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.
    2. Click the Destinations tab in the Destination Properties dialog box. Click Add.

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

    Click OK.

    1. Click Apply and then click OK in the Destination Set Properties dialog box.

    1. Close the ISA Management console.

      Note:

      You can remove the OWA related entries 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.

    Get the New Book!

    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.

    Get the Book!

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

    Summary

    In this part 4 and the final part in our series on publishing RPC over HTTP Web sites on a front-end Exchange Server, started with reviewing the settings on the Incoming Web Requests listener and then customizing them to meet our special requirements. We then reviewed the settings on the OWA publishing rule that was created by the OWA publishing wizard. We then reviewed the Destination Set created by the OWA Web publishing wizard and added an entry for /rpc*. We finished with a discussion on how to configure URLScan on the ISA Server 2000 firewall to support protecting the RPC over HTTP connections.

    Using the information in this series of article you’ll be able to successfully publish your RPC over HTTP front-end Exchange Server. If there’s enough interest, I go over

    I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=5;t=002297 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom

    About The Author

    Leave a Comment

    Your email address will not be published. Required fields are marked *

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

    Scroll to Top