HTTP 的身份验证机制

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

前端服务器通过两种方式处理身份验证：前端服务器对用户本身进行身份验证（使用基本身份验证或基于表单的身份验证），或匿名将请求转发到后端服务器。无论哪种方式，后端服务器也将执行身份验证。

注意：
如果前端服务器位于外围网络中并且无法使用远程过程调用，则要求对前端服务器进行匿名身份验证。这不是推荐的方案，因为前端服务器无法阻止用户访问。有关传递身份验证的详细信息，请参阅本主题后面的“传递身份验证”。

重要提示：
极力建议您使用双重身份验证，在双重身份验证中，前端服务器和后端服务器均配置为对用户进行身份验证。有关详细信息，请参阅本主题后面的“双重身份验证”。

双重身份验证

默认情况下，双重身份验证用于前端服务器和后端服务器。在双重身份验证中，前端服务器和后端服务器均配置为对用户进行身份验证。应将前端服务器配置为尽可能执行身份验证。如果无法在前端服务器上启用身份验证，则将无法进行隐式登录，并且无法平衡公用文件夹请求的负载。无论如何配置身份验证，均可以使用显式登录进行访问。

注意：
Exchange 依靠 IIS 对 HTTP 请求进行身份验证。IIS 使用对目录服务器的 RPC 来进行身份验证。如果在前端服务器与目录服务器之间不允许执行 RPC，则必须使用传递身份验证。有关如何启用传递身份验证以及这样做的风险的详细信息，请参阅本主题后面的“传递身份验证”。

传递身份验证

在传递身份验证中，将前端服务器配置为进行匿名身份验证，所以，不会要求用户提供授权头。前端服务器将用户请求转发到后端服务器，后端服务器要求用户进行身份验证。后端服务器的身份验证请求以及用户的响应将原封不动地通过前端服务器路由。

注意：
使用传递身份验证时，匿名 HTTP 请求直接转到后端服务器进行身份验证。只应在绝对必要时使用传递身份验证。推荐的策略是，将高级防火墙放置在外围网络中，并将前端服务器放置在内部防火墙后面，以便可以对内部网络进行完全的 RPC 访问。如果希望将前端服务器放置在外围网络中，则允许 RPC 可能比允许匿名请求到达后端服务器更加安全，因为传递身份验证允许来自任何来源（有效或无效）的请求传递到后端服务器。有关详细信息，请参阅部署前端/后端拓扑的方案。

使用传递身份验证时，前端服务器无法平衡公用文件夹请求的负载，因为没有可执行哈希算法的身份验证令牌。此外，也无法使用隐式登录。用户必须输入完整 URL（包括其用户名）才能登录。

身份验证方法

根据所使用的 Exchange 版本，前端/后端服务器体系结构可以使用多种身份验证方法。此外，与前端服务器和后端服务器之间使用的身份验证相比，客户端与前端服务器之间的身份验证可以使用不同的方法。下列各节概述两种身份验证方法。

客户端到前端服务器的身份验证

注意：
前端服务器不支持集成 Windows 身份验证（包括 NTLM 和 Kerberos 身份验证）或 HTTP 1.1 摘要式身份验证。

基本身份验证

基本身份验证是由 HTTP 规范定义的简单身份验证机制，在将用户的用户名和密码发送到服务器之前对其进行轻型编码。为了在前端/后端拓扑中实现真正的密码安全，应在客户端与前端服务器之间使用 SSL 加密。

注意：
Exchange 2000 Server 和 Exchange Server 2003 支持基本身份验证。

基本身份验证不支持单一登录。单一登录时，用户登录到运行 Windows 的计算机，根据域进行身份验证，然后，用户不必重新输入其凭据，即可访问该域中的所有资源和应用程序。如果所访问的服务器启用了集成 Windows 身份验证，则 Microsoft Internet Explorer 版本 4.0 以及更高版本允许 Web 应用程序（包括 Outlook Web Access）进行单一登录。因为前端服务器不支持集成 Windows 身份验证，所以，在用户访问 HTTP 应用程序时，前端服务器总是提示他们进行身份验证，即使已使用 Windows 登录，也必须重新输入其凭据。但是，因为浏览器进程中缓存了凭据，所以，用户只需要在每个浏览器会话中输入一次凭据即可。

重要提示：
使用网亭时应注意，如果在会话完成后无法关闭浏览器并结束浏览器进程，缓存凭据可能会带来安全风险。此风险的原因在于，下一个用户访问网亭时，用户凭据仍保留在缓存中。要在网亭上使用 Outlook Web Access，请确保可以在会话完成后关闭浏览器并结束浏览器进程。否则，请考虑使用采用双因子验证的第三方产品，在这些产品中，用户必须提供物理令牌和密码，才能在网亭上使用 Outlook Web Access。

基于表单的身份验证

注意：
只有 Exchange Server 2003 支持基于表单的身份验证。但是，可以将 Exchange 2003 Server 前端服务器与 Exchange 2000 Server 后端服务器一起使用，以利用基于表单的身份验证。

基于表单的身份验证在用户完成初始登录后，使用 Cookie 来标识用户。通过跟踪此 Cookie 的使用，Exchange 可以使不活动的会话超时。但是，初始的用户名和密码仍以明文形式传输，类似于基本身份验证。因此，基于表单的身份验证必须与 SSL 加密一起使用。有关如何配置基于表单的身份验证的信息，请参阅将前端服务器配置为采用默认域中的“为 Exchange Server 2003 配置基于表单的身份验证”一节。

前端服务器到后端服务器的身份验证

前端服务器必须将用户凭据与 Web 请求一起发送到后端服务器，以便后端服务器允许访问数据。

集成身份验证

Exchange 2003 前端服务器将使用 Kerberos 身份验证来在前端服务器与后端服务器之间保护用户凭据。如果 Kerberos 身份验证失败，将记录警告事件，并且前端服务器将尝试 NTLM。如果 NTLM 失败，将记录错误，并且将使用基本身份验证。

要使前端服务器可以使用集成身份验证，后端虚拟服务器应配置为允许集成身份验证（默认设置）。

注意：
Exchange 2003 和 Exchange 2000 后端服务器将支持从 Exchange 2003 前端服务器进行集成身份验证。

基本身份验证

前端服务器将基本身份验证凭据代理到后端服务器。为了保护此信息，极力建议在前端服务器与后端服务器之间使用 IPSec。

注意：
Exchange 2000 和 Exchange 2003 前端服务器支持在前端服务器与后端服务器之间进行基本身份验证。

用户登录信息

根据前端服务器进行身份验证时，默认情况下，用户必须输入以下格式的用户名：域\用户名。可以将前端服务器配置为采用默认域，以便用户不必记住自己的域。

另一种身份验证方法是为用户配置用户主体名 (UPN)。通常，用户的 UPN 设置为与电子邮件地址相同。这样，用户可以输入其 UPN/电子邮件地址作为用户名。有关详细信息，请参阅配置 Exchange 前端服务器。