portwineboy

My buddy has an IT consulting business that I might be doing some work for. One of his clients is thinking about ditching their VPN client for RPC over HTTP aka RPC over HTTPS.

http://office.microsoft.com/en-us/as...402731033.aspx

http://www.mcpmag.com/columns/articl...itorialsID=758

They claim their VPN is slow and subject to frequent disconnects. My feeling is that they need a new VPN provider or client as my experience with Cisco clients and AT&T clients/service has been quite positive, however, since we are not yet engaged in the job we can't investigate.

I'm wondering if anyone has experience with RPC over HTTP and can provide any insight? My fears are a) it's from Microsoft b) it's free c) relies soley on SSL as security whereas VPN SSL/SSH are only 1 part of security process and d) it's from Microsoft and free and they aren't known for secure products

For a firm with little FT IT support it seems like a bad idea given the complexity. My thought would be to point them at a AT&T type soup to nuts solution.

Any thoughts????

__________________
If you can read this, thank a teacher.
If you can read this in English, thank a veteran.

bendsley

A definition of RPC for people wondering:

A remote procedure call (RPC) is a protocol that allows a computer program running on one host to cause code to be executed on another host without the programmer needing to explicitly code for this. When the code in question is written using object-oriented principles, RPC is sometimes referred to as remote invocation or remote method invocation.

RPC is an easy and popular paradigm for implementing the client-server model of distributed computing. An RPC is initiated by the caller (client) sending a request message to a remote system (the server) to execute a certain procedure using arguments supplied. A result message is returned to the caller. There are many variations and subtleties in various implementations, resulting in a variety of different (incompatible) RPC protocols.

In order to allow servers to be accessed by differing clients, a number of standardized RPC systems have been created. Most of these use an interface description language (IDL) to allow various platforms to call the RPC. Examples of such systems include Sun RPC (sometimes called ONC RPC), the Distributed Computing Environment (DCE), Microsoft's DCOM (and ActiveX), which is based in part on DCE, and CORBA.

Recently a number of vendors have started using XML as the IDL, and HTTP as the network protocol. The advantage of this system, known as web services, is simplicity and standardization, the IDL is a text file that is widely understood, and HTTP is built into almost all modern operating systems. An example of such an RPC system is SOAP, developed in turn from XML-RPC.
===================================================================

1. Highly recommend you use ISA to front end it. As I mentioned in previous posts I used ISA's reverse proxy function to terminate a secure SSL channel at the ISA Server and then recreate another one separately to Exchange...why? primary reason is security. Secondary reason is that you can use OWA forms based logon with SSL and use the great compression functions that it now has.

2. You need Windows Server 2003 DCs and GCs in order for it to work. Also Exchange 2003 must be running on Windows Server 2003. Patch both the Windows Server install and get Exchange 2003 SP1 on aswell.

3. Install the RPC over HTTP service on the Exchange Server from Add/Remove programs.

4. Follow Q article 833401. If you have deployed Exchange 2003 SP1 it makes it a lot easier and you wont need to type as much in in terms of the registry settings that are required. You will need to add a registry setting to each GC though that Exchange will be accessing.

Test it by going to the https://mail.servername.com/rpc and authenticating. If it comes back and says "HTTP Error 403.2 - Forbidden: Read access is denied" then youve done everything right!

5. You need to configure your Outlook clients to use it as an option. You configure it in your email settings/Exchange Server settings, then the Connections tab and finally Exchange Proxy settings. You can just fill in the FQDN of your mail server thats being reverse proxied and if you want the next level of security to mutually authenticate then you need to put that in aswell. Tick the "On Slow networks connect using HTTP first then TCP/IP" and choose basic text authentication. Obviously, because you're using SSL to encrypt the channel your basic text credentials wont be compromised.

The client computer must be running Microsoft Windows XP Professional Service Pack 1 (SP1), and the update package that is described in the following Microsoft Knowledge Base article must be installed:

331320 Outlook 2003 performs slowly or stops responding when connected to Exchange Server 2003 through HTTP.
Note: The update package that is described in article 331320 is included in Microsoft Windows XP Professional Service Pack 2 (SP2). If you have installed Windows XP SP2, you do not have to install the update package that is described in article 331320.


-------------------------------------------------------------------
I implemented VPN where I work and it's fully what I suggest. This might be able to help you in getting started though.

__________________
"You hear the one about the fella who died, went to the pearly gates? St. Peter let him in. Sees a guy in a suit making a closing argument. Says, "Who's that?" St. Peter says, "Oh, that's God. Thinks he's Denny Crane."

kurty[B]

I deal with RPC over HTTP quite a bit at my job. I like it, and think it's a great feature. Setting it up can be a little bit tricky, but once it is up and running it works very well.

If the client is running Windows XP SP2 they should not have to install the patch to use RPC over HTTP. If you need the link to that patch, or have some questions or problems (ie... Patch installed, but the Exchange over the Internet feature still does not show up on the client) I have some batch files and regkeys that make it show up.

Let me know if you have any client side questions.

bendsley

Note: The update package that is described in article 331320 is included in Microsoft Windows XP Professional Service Pack 2 (SP2). If you have installed Windows XP SP2, you do not have to install the update package that is described in article 331320.

yup, covered that already chief.

__________________
"You hear the one about the fella who died, went to the pearly gates? St. Peter let him in. Sees a guy in a suit making a closing argument. Says, "Who's that?" St. Peter says, "Oh, that's God. Thinks he's Denny Crane."

flightlessbird

sory for the hijack, but;
This sounds scary, do you ever have people masquerade attacks on this as lagitamate HTTP traffic? It sounds like you are adding another layer of obscurity to pick this stuff out of. Is it easy to filter it with an IDS?

bendsley

Anything HTTP will go to its own port on it's own server. This uses HTTPS via encrypted SSL tunnels. As mentioned above, you would also want something like an ISA server to sit in front of the exchange box to filter what goes where and do inspection.

__________________
"You hear the one about the fella who died, went to the pearly gates? St. Peter let him in. Sees a guy in a suit making a closing argument. Says, "Who's that?" St. Peter says, "Oh, that's God. Thinks he's Denny Crane."

portwineboy

Thanks very much guys, extremely helpful info and greatly appreciated. I will certainly go the ISA server route for filtering if we set up this system.

If we get the go ahead I'll probably be back with more.

__________________
If you can read this, thank a teacher.
If you can read this in English, thank a veteran.