RPC over HTTP Authentication and Security

Switch on low bandwidth view

Collapse All

Topic Last Modified: 2005-05-18

The authentication and security benefits of using RPC over HTTP are the following:

You do not have to allow any Internet ports other than those you already allow for Microsoft® Office Outlook® Web Access, Microsoft Exchange ActiveSync®, or Outlook Mobile Access.
You must use Secure Sockets Layer (SSL).
Outlook must send authenticated requests.
Both the RPC proxy server and the Exchange server authenticate Outlook requests that use RPC over HTTP.
You do not expose the end point mapper.
Client computers can access only specified Exchange services on specified Exchange servers.

HTTP Authentication

Internet Information Services (IIS) on the RPC proxy server controls the HTTP session authentication. When you configure the RPC proxy server, you must set the RPC virtual directory to use Basic authentication, NTLM authentication, or both Basic authentication and NTLM authentication. Outlook can send either Basic authentication or NTLM authentication for the HTTP session, depending on how you have configured the Outlook profile. The RPC proxy server Internet Server API (ISAPI) does not accept anonymously authenticated connections.

Note:
When you use Exchange System Manager in Exchange Server 2003 Server Pack 1 (SP1) to configure RPC over HTTP, Exchange System Manager automatically configures the authentication settings on the RPC virtual directory for you.

Note:
NTLM authentication is also known as Integrated Windows authentication.

The authentication mechanism that you configure in your Outlook profile is used only for the HTTP session to the RPC proxy server. The authentication mechanism between Outlook and the Exchange server, when Outlook accesses the Exchange server by using RPC over HTTP, is always NTLM. It is strongly recommended that you use SSL encryption for the HTTP session to the RPC proxy server, especially if you use Basic authentication for the HTTP session. If you use SSL encryption, you prevent your user name and password from being sent in clear text. Outlook does not allow you to use Basic authentication when connecting to your RPC proxy server without using SSL encryption.

If you have a firewall that examines HTTP traffic and modifies it in any way, you may have to use Basic authentication, instead of NTLM authentication. NTLM authentication fails if the RPC proxy server does not trust the authentication information. For example, you may have a firewall that ends the session from the Internet and establishes a new session to the RPC proxy server, instead of passing the HTTPS (SSL) session to the Exchange server without modification. This process is known as reverse proxying or Web publishing. Certain firewalls, such as Microsoft Internet Security and Acceleration (ISA) Server 2004, can successfully reverse proxy or Web publish the session and still permit NTLM authentication to succeed.

Note:
ISA Server 2000 cannot reverse proxy or Web publish the session and still permit NTLM authentication to succeed.

Basic authentication is not affected by reverse proxying or Web publishing and works regardless of firewalls. However, if you use Basic authentication, you must type your domain, user name, and password every time that you start an Outlook session.

Basic Authentication and NTLM Authentication

The following table illustrates some of the differences between Basic authentication and NTLM authentication.

Basic authentication	NTLM authentication
The client computer sends user name and password in clear text. You should always use SSL when you use Basic authentication. Outlook does not allow you to select Basic authentication without also selecting SSL. The RPC proxy server also requires SSL.	The client computer sends a logon request to the server. The server replies with a randomly generated "token" or challenge to the client computer. The client computer hashes the currently logged-on user's cryptographically protected password with the challenge and sends the resulting "response" to the server. The server receives the challenge-hashed response and compares it to what it knows to be the appropriate response. (The server takes a copy of the original token, which it generated, and hashes it against what it knows to be the user's password hash from its own user account database.) If the received response matches the expected response, the user is successfully authenticated to the host.
Basic authentication works with reverse proxy firewalls.	NTLM authentication may not work with some reverse proxy firewalls. If the firewall examines the traffic and modifies it, the NTLM authentication can be invalidated.
Basic authentication requires the user to enter domain, user name, and password.	NTLM can use the current Microsoft Windows® operating system logon information.

Basic authentication

NTLM authentication

The client computer sends user name and password in clear text.

You should always use SSL when you use Basic authentication.

Outlook does not allow you to select Basic authentication without also selecting SSL.

The RPC proxy server also requires SSL.

The client computer sends a logon request to the server.

The server replies with a randomly generated "token" or challenge to the client computer.

The client computer hashes the currently logged-on user's cryptographically protected password with the challenge and sends the resulting "response" to the server.

The server receives the challenge-hashed response and compares it to what it knows to be the appropriate response. (The server takes a copy of the original token, which it generated, and hashes it against what it knows to be the user's password hash from its own user account database.)

If the received response matches the expected response, the user is successfully authenticated to the host.

Basic authentication works with reverse proxy firewalls.

NTLM authentication may not work with some reverse proxy firewalls.

If the firewall examines the traffic and modifies it, the NTLM authentication can be invalidated.

Basic authentication requires the user to enter domain, user name, and password.

NTLM can use the current Microsoft Windows® operating system logon information.

Requirements for RPC over HTTP to Use the Current Windows Operating System Logon Information

For RPC over HTTP to use the current Windows operating system logon information, the following requirements must be met:

The user logs on to the client computer with correct domain credentials.
The user selects NTLM authentication in the Outlook profile.
The firewall allows NTLM authentication. This can occur if the firewall is just passing the SSL session to the Exchange server without modification (port filtering), or if the firewall is an advanced firewall, such as ISA Server 2004. ISA Server 2004 can reverse proxy Web publish the Exchange server and still permit NTLM authentication to succeed.
The user automatically sends NTLM authentication information with the connection. This occurs if either of the following conditions is true:
- You configure Outlook to perform mutual authentication over SSL. This is the recommended method.
- The client computer’s LmCompatibilityLevel is set to 2 or 3.

For more information about setting the LmCompatibilityLevel, see Microsoft Knowledge Base article 820281, "You must provide Windows account credentials when you connect to Exchange Server 2003 by using the Outlook 2003 RPC over HTTP feature" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=820281).

RPC Authentication

The RPC requests that the Exchange server authenticates always use NTLM authentication.

SSL

The client computer must trust the certificate that is used for SSL. For the client computer to trust the certificate that is used for SSL, the following conditions must be true:

The name of the certificate matches the Web site that is being accessed.
The certificate has not expired.
The client computer trusts the certification authority that issued the certificate.

If you have already successfully configured Outlook Web Access, Exchange ActiveSync, or other Web services to use your front-end Exchange server, the certificate meets these requirements.

You can locate the RPC virtual directory by using Microsoft Internet Explorer to verify that the certificate is correct. If the certificate is invalid, Internet Explorer issues a warning.

SSL Offloading

SSL offloading occurs when the firewall in front of the RPC proxy server quits the SSL session and establishes a new non-SSL session to the front-end server. Specifically, it does not establish a new SSL session.

If you use SSL offloading, you must set a registry key to tell the RPC proxy server that it can accept a non-SSL session. For detailed information about how to set this registry key, see How to Configure the RPC Proxy Server to Allow for SSL Offloading on a Separate Server.