Testing RPC over HTTP through ISA Server 2006 Part 1; Protocols, Authentication and Processing

Article
08/13/2007

The Protocols

One of the most difficult propositions for any ISA administrator is that of testing a traffic path through ISA. Frequently, you run face-first into the “chicken-and-egg” problem of having to test the traffic path using the application designed to make use of it. When this works life is good, water is cool & clear and the breeze is warm and light on your face. When the application test fails, you’re frequently left with few if any options to differentiate between it, ISA, the server application, the network, etc., etc...

RPC over HTTP is one of those protocols that can frustrate even the most seasoned network or firewall engineer. It “stretches the limits” of the HTTP protocol, causing some interesting behavior when it passes through some application-aware firewalls and proxies. Figure 1 summarizes RPC over HTTP traffic flow through ISA. The dotted box serves to indicate that the RPC Proxy and mailbox servers may be the same or separate hosts. Recognizing this particular point will be significant to your troubleshooting efforts.

Fig. 1

I won’t entertain the discussion of “RPC over HTTP” vs. “RPC over HTTPS” other than to point out that this distinction only serves to confuse an already complex process. HTTPS is nothing more than HTTP encrypted using SSL or TLS. Neither the RPC nor the HTTP protocols themselves are changed by the fact that they’re carried within a secure session. If you absolutely must make the distinction between HTTP and HTTPS, you would actually be more correct in saying “RPC over HTTP over SSL”. Unfortunately, this distinction begins to get a bit unwieldy if the traffic is also carried within a PPTP tunnel through your GPRS provider by way of your mobile device through which your laptop is tethered, creating an “RPC over HTTP over SSL over PPTP over GPRS” traffic process (say that three times while inebriated). ..so let’s just stick with RPC over HTTP, shall we?

Also, while this discussion centers on Exchange RPC over HTTP, you should bear in mind that Exchange is not the only client/server application to make use of this transport. Windows 2007 Terminal Services Gateway and the Terminal Services Client v6 can make use of RPC over HTTP. You can reasonably expect to see other client / server applications make use of this protocol translation in the future.

Figures 2 through 4 illustrate the traffic processing and translation points. I’ve intentionally limited the traffic representations to the “outermost” protocol for clarity.

“MAPI” is Exchange RPC

“HTTP” is “MAPI inside HTTP”

“SSL” is “MAPI inside HTTP inside SSL”.

What you should bear in mind is that authentication generally occurs at each protocol transition point (Client, ISA, RPC Proxy, RPC Server). Note that the ISA Web Listener and Web Proxy are shown as separate mechanisms only to illustrate the HTTP processing within the Web Proxy.

Fig 2

Fig 3

Fig 4

ISA Bridging Scenarios

There are two ISA bridging scenarios we’re interested in, each with two variations on the theme. These are interesting to this discussion because they each dictate specific configurations at the client, ISA and RPC Proxy. ISA Server provides the option of accepting either plain-text or encrypted HTTP traffic from the client and passing it upstream to the published server using either plain-text or encrypted HTTP. When the inbound and outbound protocols are the same, we call this “symmetric bridging”. When they differ, we call this “asymmetric bridging” (at least I do – you should be feeling my Jedi mind powers about now…). I define each primary protocol according to whether or not encryption is used between the client and ISA, since this is the primary connection without which there is no traffic to bridge. Note that asymmetric bridging could also include FTP to the upstream (published) server regardless of the primary protocol, but is not a functional alternative for RPC over HTTP. Also, neither tool knows nor cares what protocol you choose between ISA and the RPC Proxy server because as far as they’re both concerned, ISA is the RPC Proxy server.

HTTPS Bridging (AKA “SSL Bridging”)

Fig 5 (Symmetric)

Fig 6 (Asymmetric)

HTTP Bridging

Fig 7 (Symmetric)

Fig 8 (Asymmetric)

The Problems

Not a simple task

Because RPC over HTTP is more complex than simple transport-port data-passing and it employs multiple authentication points and methods, accurately testing RPC over HTTP requires the tester to evaluate this traffic based on the following criteria:

Protocols:

RPC

HTTP

SSL/TLS

Authentication & processing stages:

Client

Forward Proxy (if used)

Reverse Proxy (bridging)

RPC Proxy

RPC Server

Ill-conceived (although well-intentioned) advice

Some folks have suggested that using your browser is a valid technique for testing the RPC Proxy service, and since both RPC over HTTP and browsers use HTTP, this would appear to be a good idea. There are several problems with that theory, though:

1. RPC over HTTP defines two new HTTP methods that are unknown (and cannot be specified) to any browser:

RPC_IN_DATA (data from the RPC client to the RPC server)

RPC_OUT_DATA (data from the RPC server to the RPC client)

2. Entering a URL in your browser’s address bar and hitting <ENTER> causes the browser to use a GET method.

3. Sending a GET request to http://host.domain.tld/rpc/rpcproxy.dll actually produces a “503 Must use POST” error response from the RPC Proxy.

4. The “503” response from RPC Proxy results in a blank browser window only if you connect directly to the RPC Proxy server itself. If you think “no news is good news”, then this test result should please you. I strongly discourage the use of such non-deterministic techniques, however.

5. Issuing such a command through ISA Exchange Web Publishing produces one of two possible errors in the browser, depending on whether you’ve published the RPC Proxy using the Exchange 2003 or Exchange 2007 publishing wizard. The error you receive from ISA in each case will be:

a. (2003 wizard) - Error Code: 500 Internal Server Error. The pipe is being closed. (232)

b. (2007 wizard) - Error Code 64: Host not available

Because browser-based tests produce error or empty responses even for successful tests, this test methodology is pretty useless and must not be used. Please feel free to send me any documents you find that espouse this methodology and I’ll work to get them changed.

Note that while Outlook cannot be configured to combine unencrypted HTTP and Basic authentication, RPCPing can do this and as a result, can frequently make for a more accurate problem assessment by the troubleshooter; especially if you’re familiar with analyzing HTTP traffic using a network capture tool such as Network Monitor 3.

We’ll continue this discussion in part 2, where we define our test strategies and test tool usage.

Happy testing,

Jim Harrison

Program Manager, ISA SE

Comments

Anonymous
January 01, 2003
What is a “SAN”? “SAN” in this context refers to the certificate attribute “Subject Alternative Name”.
Anonymous
January 01, 2003
Yuri Diogenes has blogged about how to troubleshoot an OWA publishing rule on ISA Server 2006. Sometimes
Anonymous
January 01, 2003
The ISA server team has posted a guide on the subject (in three parts). The guide covers most aspects
Anonymous
January 01, 2003
The ISA server team has posted a guide on the subject (in three parts). The guide covers most aspects
Anonymous
January 01, 2003
PingBack from http://blogs.isaserver.org/pouseele/2007/08/14/testing-rpc-over-http-through-isa-server-2006/

Partager via