The same method applies when publishing RPC/HTTP on either ISA or TMG 2010

Create the RPC/HTTP Web Publishing Rule

Now that we have the two OWA Web Publishing Rules in place we can move along to our next task: creating the Web Publishing Rule for the RPC/HTTP site on the Client Access Server. Remember, our goal here is to use the same Web Listener for all of our rules, so we do not need to worry about creating a new Web Listener, something that would not have worked in previous version of the ISA Firewall.

Click on the Firewall Policy node in the left pane for the ISA Firewall console and then click the Tasks tab on the Task Pane. On the Tasks tab, click the Publish Exchange Web Client Access link.

Figure 22

On the Welcome to the New Exchange Publishing Rule Wizard page, enter a name for the Web Publishing Rule. In this example, we will name the rule Outlook Anywhere and then click Next.

Figure 23

On the Select Services page, select the Exchange Server 2007 option from the Exchange version drop down list box. Put a checkmark in the Outlook Anywhere (RPC/HTTP) checkbox and also put a checkmark in the Publish additional folders on the Exchange Server for Outlook 2007 clients checkbox. I do not know what those folders are, but it cannot hurt to put a checkmark in that checkbox and then find out which paths will be published. Click Next.

Figure 24

On the Publishing Type page, select the Publish a single Web site or load balancer option and click Next.

Figure 25

On the Server Connection Security page, select the Use SSL to connect to the published Web server or server farm and then click Next.

Figure 26

On the Internal Publishing Details page, put the common/subject name on Web site certificate bound to the OWA Web site on the Client Access Server. In our current example, the common name on the Web site certificate bound to the OWA Web site on the Client Access Server is owa.msfirewall.org, so we will enter owa.msfirewall.org in the Internal site name text box. Remember, the Internal site name bears no relation at all to the actual name of the Client Access Server, the name you put there is the common/subject name on the Web site certificate.

Put a checkmark in the Use a computer name or IP address to connect to the published server. Then use the Browse button to find the name of the Client Access Server, as seen in the figure below.

Figure 27

As you can see in the figure below, the Internal site name is not the same as the computer name of the Client Access Server. Click Next.

Figure 28

On the Public Name Details page, select the This domain name (type below) option from the Accept requests for drop down list. In the Public name text box, enter the name that external users will use to connect to the ISA Firewall in order to reach the RPC/HTTP site.

Figure 29

On the Select Web Listener page, select the SSL listener you created earlier from the Web listener drop down list and click Next.

Figure 30

On the Authentication Delegation page, select NTLM authentication from the Select the method used by the ISA Firewall to authenticate to the published Web server drop down list. Because the Outlook RPC/HTTP client does not know what to do with the forms-based authentication page, the ISA Firewall will detect that a non-browser client is connecting to the Web Listener and will fail back to basic authentication. The Outlook RPC/HTTP client will then use Basic authentication to authenticate to the ISA Firewall. The ISA Firewall will then authenticate and authorize the user. If the user is authenticated and authorized, the ISA Firewall will forward the user’s credentials as NTLM credentials. I know this sounds like magic and that it should not work, but by the time we are done, I think you will find that it does work.

By the way, this does not solve the problem related to users having to authenticate each time they open Outlook to connect to the RPC/HTTP proxy through the ISA Firewall. The reason for this is that in order to bypass by entering credentials, you would have to bypass pre-authentication at the ISA Firewall and allow NTLM credentials directly to the Client Access Server. That would be a foolhardy move and obviates the security provided by the ISA Firewall, as it allows every hacker on the Internet free access to anonymous connections to your RPC/HTTP proxy, and when the zero-day comes that someone exploits the RPC/HTTP proxy, you will be sorry that you did not take my advice.

Click Next.

Figure 31

On the User Sets page, accept the default All Authenticated Users and click Next.

Figure 32

Review the settings on the Completing the New Exchange Published Rule Wizard page and click Next.

Figure 33

Double click on the Outlook Anywhere Web Publishing Rule and click the Paths tab. Notice that a number of paths other than the /rpc/* directory have been added. As you can see in the figure below the following paths have been added:

/unifiedmessaging/*

/rpc/*

/OAB/*

/ews/*

/AutoDiscover/*

What are they all used for? I cannot tell you definitively, but maybe someone over at www.msexchange.org can. What I do know is that the /rpc/* path allows connections to the RPC/HTTP proxy, which is what we are mostly interested in at this time.