Continuing the blogcast series on infrastructure essentials.
By popular demand (so you can all stop emailing me now please!), we're going to tackle the subject of RPC over HTTP in the next 10 or 11 parts. First, I feel it important to set the scene to paint a clearer picture of what we are trying to achieve, and some of the security considerations we need to be sure of.
RPC/HTTP (or HTTPS as you will also see it called, given security is a good thing) is used by Outlook 2003 to communicate back to Exchange 2003 through a firewall such as ISA Server. Which, co-incidentally happens to match the exact configuration we have in our environment. RPCs (Remote Procedure Calls) typically using a broad range of ports, and opening those through a firewall isn't the safest option to you. RPC over HTTP provides a means to encapsulate RPC traffic into HTTPS packets using port 443 which is frequently available and open through firewalls.
While tunnelling through port 443 is good, please open your eyes to a few things here. Your firewall must as a minimum do two things. Firstly, rather than blindly pass the encapsulated RPC traffic straight through, it must to be able to inspect the traffic to provide you with a secure and solid layer of protection. To do this, we have a problem which is where the second requirement of your firewall comes in. HTTPS traffic is encrypted using SSL, and only the recipient web-server should hold the private key to decrypt the traffic. If the recipient web server was not your firewall, the firewall would not be able to inspect any traffic. Hence, the second requirement is the ability to provide SSL termination. This is where inbound traffic encrypted from the Internet is de-crypted at the firewall for inspection prior to entry into your LAN. After inspection, traffic passed to your corporate network can optionally be re-encrypted for an additional layer of security.
We also have another problem. Without going into the fundamentals of TCP/IP programming (although I could wax lyrical for many hours if you are interested - part of my background was to write a TCP/IP stack, so I feel I know a fair bit there), on a single IP address (generally) only a single process can be bound and listening on a particular TCP port. The port in question I'm referring to is 443, that used by SSL. If you've been following the series, you know that within our infrastructure, port 443 is listening on the ISA server using the OWA Forms-Based-Authentication web listener. RPC/HTTP(S) requires us to be listening with basic or integrated authentication. ISA does not support combining FBA with Basic or Integrated auth. We could say to users, sorry you can't have OWA - it's Outlook thick client only. However, that won't go down well. But then, what about if we wanted to host our Internet site internally and have a section of it also available on port 443. Or an Extranet sharepoint server? No, we need to think again. Fortunately, there is a way to resolve this without having a more expensive luxury of multiple external IP addresses as will be seen throughout the series.
So, hopefully you now have a feel for where we are headed over the next few weeks. The first part here walks through the network diagram and sets up the essential RPC/HTTP proxy component built into Windows Server needed for this solution to work. For the first few parts, we will concentrate on getting Outlook 2003 to communicate with Exchange 2003 internally using RPC/HTTP. This is an essential first step as you don't complicate matters by introducing the firewall straight away, and it validates that the configuration is sound. After all, if it doesn't work internally, you'll be scratching your head for hours when you throw the firewall into the mix.
For those itching to get ahead of the game, here's a KB article partly covering this type of configuration with a single Exchange server in your organisation. For more deployment scenarios, particularly if you have multiple Exchange Servers including both front-end (FE) and back-end (BE), take a look at the Technet articles here.
Click here to view.
Series Index:
0. Network configuration and series background.
1. Getting started
2. ISA Server configuration to allow basic web browsing capability
3. ISA Firewall Client basic configuration
4. ISA Firewall Client auto-detection through WPAD configuration
5. Configuring an Exchange mailbox and Outlook profile
6. Fixing 0x8004010F on Outlook send/receive
7. Installing our first Certificate Authority
8. Publishing OWA through ISA using Forms Based Authentication
9. OWA /exchange redirection
10. OWA nearly goes SSL - we have a certificate
11. OWA is available over SSL/HTTPS
12. Sending external email - Configuring outbound SMTP
13. Mail retrieval through POP3 polling
14. Preparations for Email retrieval through SMTP Transfer
15. Completing Email retrieval through SMTP Transfer