Security and Connection Frequently Asked Questions

While this page does not claim to have detailed information about the extensive Security questions you may have, here are some frequently asked questions about RPC over HTTP and security:

Q: What is the architecture of this connection; does it use HTTP all the way to my server?
A: No - the difficult part of reaching your server from outside the firewall is solved by using HTTP, an internet routable protocol. Outlook by default will connect using HTTPS to an internet-facing RPC Proxy server in your organization. (That's why you need to configure RPC/HTTP - we need to know how to reach this additional server.) Once the HTTPS communication is authenticated, we send RPCs through the HTTP tunnel where the RPC Proxy then forwards them to your Exchange Server in RPC format (not HTTP). The RPC Proxy server is configured so that only certain servers and certain ports will be forwarded after valid authentication. This model is very similar to the Front End / Back End model that OWA uses to connect to Exchange using a web browser, only the Front End only proxies data between Outlook and Exchange instead of painting the view like the OWA Front End server does.

Q: Do I have to put my Exchange Servers on the Internet for this to work?
A: No. RPC over HTTP allows you to leave your existing internet-facing servers in place, and upgrade them to Windows.NET Server 2003 to run the RPC over HTTP proxy service on them. It proxies through the IIS 6 service and forwards to only the servers behind the firewall that you've specified via a registry key.

Q: This sounds cool, but I'm worried about the authentication. How does that work?
A: The RPC API allows us to currently use Basic and NTLM authentication over HTTP. However, everything can be transacted via an SSL encrypted channel (default). No credentials are passed until the SSL channel is established, and nothing is passed outside the SSL channel. RPC over HTTP can authenticate and verify the Server's identity by comparing its common name and/or certification path against a pre-configured and valid name. When mutually authenticating, RPC will not establish an SSL connection unless the comparison succeeds. Again, no credentials are exchanged until a valid and trusted SSL channel is established.

Q: How does Outlook decide when to use HTTP and when to use TCP/IP?
A: First, Outlook cannot connect using HTTP unless it is properly configured. Given that you're configured to use HTTP, Outlook has two separate behaviors depending on network adapter speed.

If Outlook detects a fast connection (>128 kbps, defined by your network adapter):

1. we first attempt TCP

2. and then failover to HTTP if unsuccessful.

If Outlook detects a slow connection (<=128 kbps, defined by your network adapter):

1. we first attempt HTTP
2. and then failover to TCP if unsuccessful.

Both of these connection orders are configurable. This logic allows us to always successfully connect when there's a network connection available with access to your RPC Proxy Server.

Q: What happens when I hibernate my computer on the LAN and wake it up in a hotel room?
A: Outlook's connection logic works the same for every reconnect as well as reboot. This means that we'll first detect your network adapter and then follow the logic above (or the admin configured logic). Even walking out of an 802.11b wireless LAN access point and transitioning to a cellular-based network will transition you from a TCP-based connection to an HTTP connection automatically.