RPC over HTTP 身份验证和安全

项目
10/25/2013

上一次修改主题： 2005-05-18

使用 RPC over HTTP 时获得的身份验证和安全优点包括：

除已经允许用于 Microsoft® Office Outlook® Web Access、Microsoft Exchange ActiveSync® 或 Outlook Mobile Access 的端口以外，您不必允许任何其他 Internet 端口。
必须使用安全套接字层 (SSL)。
Outlook 必须发送身份验证请求。
RPC 代理服务器和 Exchange 服务器都会对使用 RPC over HTTP 的 Outlook 请求进行身份验证。
不会公开终点映射器。
客户端计算机只能访问指定 Exchange 服务器上的指定 Exchange 服务。

HTTP 身份验证

RPC 代理服务器上的 Internet 信息服务 (IIS) 控制 HTTP 会话身份验证。配置 RPC 代理服务器时，必须将 RPC 虚拟目录设置为使用基本身份验证和/或 NTLM 身份验证。Outlook 可以根据您对 Outlook 配置文件进行的配置，为 HTTP 会话发送基本身份验证或 NTLM 身份验证。RPC 代理服务器 Internet 服务器 API (ISAPI) 不接受匿名身份验证的连接。

注意：
当您使用 Exchange Server 2003 Server Pack 1 (SP1) 中的 Exchange 系统管理器来配置 RPC over HTTP 时，Exchange 系统管理器会自动为您配置针对 RPC 虚拟目录的身份验证设置。

注意：
NTLM 身份验证将也称为集成 Windows 身份验证。

您在 Outlook 配置文件中配置的身份验证机制仅用于与 RPC 代理服务器的 HTTP 会话。当 Outlook 通过使用 RPC over HTTP 访问 Exchange 服务器时，Outlook 和 Exchange 服务器之间的身份验证机制总是 NTLM。极力建议您对与 RPC 代理服务器的 HTTP 会话使用 SSL 加密，在对 HTTP 会话使用基本身份验证的时候尤应如此。如果使用 SSL 加密，就可以防止以明文形式发送用户名和密码。不使用 SSL 加密而连接到 RPC 代理服务器时，Outlook 禁止使用基本身份验证。

如果您的防火墙检查 HTTP 通信并以任何方式修改它，则可能必须使用基本身份验证，而不是 NTLM 身份验证。如果 RPC 代理服务器不信任身份验证信息，则 NTLM 身份验证将失败。例如，您的防火墙可能会结束与 Internet 的会话并建立与 RPC 代理服务器的新会话，而不是不经修改即将 HTTPS (SSL) 会话传递到 Exchange 服务器。此过程称为“反向代理”或“Web 发布”。某些防火墙（如 Microsoft Internet Security and Acceleration (ISA) Server 2004）可以在成功反向代理或 Web 发布会话的同时，还允许成功进行 NTLM 身份验证。

注意：
ISA Server 2000 无法在反向代理或 Web 发布会话的同时，还允许成功进行 NTLM 身份验证。

基本身份验证不受反向代理或 Web 发布的影响，其运作与防火墙无关。但是，如果使用基本身份验证，则每次启动 Outlook 会话时都必须键入域、用户名和密码。

基本身份验证和 NTLM 身份验证

下表说明基本身份验证和 NTLM 身份验证之间的一些区别。

基本身份验证	NTLM 身份验证
客户端计算机以明文形式发送用户名和密码。使用基本身份验证时应始终使用 SSL。 Outlook 不允许您在不同时选择 SSL 的情况下选择基本身份验证。 RPC 代理服务器也要求 SSL。	客户端计算机向服务器发送登录请求。服务器用随机生成的“令牌”或质询答复客户端计算机。客户端计算机使用该质询对当前登录用户的经加密保护的密码进行哈希处理，并将结果“响应”发送到服务器。服务器接收经过哈希处理的质询响应，并将该响应与它所知道的正确响应进行比较。（服务器采用它生成的原始令牌的副本，并根据它知道是来自其自己的用户帐户数据库中该用户的密码哈希对其进行哈希处理。）如果收到的响应与预期响应匹配，则用户成功通过主机的身份验证。
基本身份验证可与反向代理防火墙一起使用。	NTLM 身份验证可能无法与某些反向代理防火墙一起使用。如果防火墙检查并修改通信，则可能使 NTLM 身份验证无效。
基本身份验证要求用户输入域、用户名和密码。	NTLM 可使用当前 Microsoft Windows® 操作系统登录信息。

客户端计算机以明文形式发送用户名和密码。

使用基本身份验证时应始终使用 SSL。

Outlook 不允许您在不同时选择 SSL 的情况下选择基本身份验证。

RPC 代理服务器也要求 SSL。

客户端计算机向服务器发送登录请求。

服务器用随机生成的“令牌”或质询答复客户端计算机。

客户端计算机使用该质询对当前登录用户的经加密保护的密码进行哈希处理，并将结果“响应”发送到服务器。

服务器接收经过哈希处理的质询响应，并将该响应与它所知道的正确响应进行比较。（服务器采用它生成的原始令牌的副本，并根据它知道是来自其自己的用户帐户数据库中该用户的密码哈希对其进行哈希处理。）

如果收到的响应与预期响应匹配，则用户成功通过主机的身份验证。

基本身份验证可与反向代理防火墙一起使用。

NTLM 身份验证可能无法与某些反向代理防火墙一起使用。

如果防火墙检查并修改通信，则可能使 NTLM 身份验证无效。

基本身份验证要求用户输入域、用户名和密码。

NTLM 可使用当前 Microsoft Windows® 操作系统登录信息。

RPC over HTTP 使用当前 Windows 操作系统登录信息的要求

要让 RPC over HTTP 使用当前 Windows 操作系统登录信息，必须满足下列要求：

用户使用正确域凭据登录到客户端计算机。
用户在 Outlook 配置文件中选择 NTLM 身份验证。
防火墙允许 NTLM 身份验证。如果防火墙只是在未经修改（端口筛选）的情况下将 SSL 会话传递到 Exchange 服务器，或者如果防火墙是高级防火墙，如 ISA Server 2004，就可能出现这种情况。ISA Server 2004 可在反向代理或 Web 发布 Exchange 服务器的同时，还允许成功进行 NTLM 身份验证。
用户自动发送与连接相关的 NTLM 身份验证信息。如果满足下列条件之一，就会发生这种情况：
- 配置 Outlook 以通过 SSL 执行相互身份验证。这是推荐采用的方法。
- 客户端计算机的 LmCompatibilityLevel 设置为 2 或 3。

有关设置 LmCompatibilityLevel 的详细信息，请参阅 Microsoft 知识库文章 820281“使用 Outlook 通过 HTTP 连接到 Exchange Server 2003 时必须提供 Windows 帐户凭据”(https://go.microsoft.com/fwlink/?linkid=3052&kbid=820281)。

RPC 身份验证

Exchange 服务器进行身份验证的 RPC 请求始终使用 NTLM 身份验证。

SSL

客户端计算机必须信任用于 SSL 的证书。要让客户端计算机信任用于 SSL 的证书，必须满足下列条件：

证书的名称与正在访问的 Web 站点匹配。
证书尚未过期。
客户端计算机信任颁发证书的证书颁发机构。

如果您已经成功配置 Outlook Web Access、Exchange ActiveSync 或其他 Web 服务以使用您的前端 Exchange 服务器，则证书满足这些要求。

您可以通过使用 Microsoft Internet Explorer 找到 RPC 虚拟目录，以验证证书是正确的。如果证书无效，Internet Explorer 会发出警告。

SSL 减负

当 RPC 代理服务器前面的防火墙退出 SSL 会话并建立新的与前端服务器的非 SSL 会话时，会发生 SSL 减负。具体地说，它不会建立新的 SSL 会话。

如果使用 SSL 减负功能，就必须设置注册表项告知 RPC 代理服务器它可以接受非 SSL 会话。有关如何设置此注册表项的详细信息，请参阅如何配置 RPC 代理服务器以允许在单独服务器上使用 SSL 减负功能。