【IT168 技术文档】虽然 SharePoint 提供了多个身份验证选项和身份验证区域，但在 Intranet 方案中企业实现的两个最常见选项还是 NTLM 和 Kerberos。这两种协议都用于典型的质询/响应方案中的集成 Windows 身份验证。NTLM 依赖于 IIS 在质询过程中生成令牌，将令牌发送到客户端，客户端用令牌进行响应，域控制器验证该响应。NTLM 要求在传输用户名和密码之前必须对它们进行加密，还要求在访问新网络资源时重新进行身份验证(新令牌)。相反，Kerberos 则依赖于一个票证系统，其中的客户端和服务器访问一个名为密钥发行中心 (KDC) 的受信任颁发机构，KDC 将响应客户端请求，并授予相应票证，客户端可以使用该票证访问网络资源。Kerberos 不需要重新进行身份验证来访问多个资源。
当前的大部分文档都提倡使用 NTLM，除非是有某种特别迫切的需求，例如具有高安全服务级别协议的网站面临的需求。即便在这种情况下，如果您进一步深究的话，使用 NTLM 仍是您的首选：它更易于实现，无需额外步骤，而且能够减少支持问题。例如，知识库文章 832769 写道：“…或无法配置服务主体名称 (SPN)，请选择 NTLM 身份验证。如果您选择 Kerberos 身份验证但无法配置 SPN，则只有服务器管理员能够通过 SharePoint 网站的身份验证。”这个说法在技术上是准确的，但它似乎有一层隐含意思：配置 SPN 过于复杂，除非有人要求实现 Kerberos，否则都应对 Kerberos 避而远之。但事实是，如果您了解原理，实现 Kerberos 并不是那么困难。
我们有很多合理的理由来解释为什么应该转换到 Kerberos，或者在新实现的系统中自始至终使用 Kerberos，但在大多数情况下，这些理由都可以归结为性能或安全性。随着用户负载或拓扑复杂性的增加，NTLM 可能会引发性能问题，因为在很多 SharePoint 使用方案中(例如访问 SharePoint Web 部件或自定义 Web 服务的 Web 应用程序)，基于 NTLM 的身份验证必定需要在 IIS 和域控制器之间多次往返。如果通过低速或高延迟链路来访问域控制器，则很有可能出现性能问题。就安全性而言，采用网络资源显式委派的基于票证的系统 (Kerberos) 在设计上比只加密用户凭据的方法更为安全。而且它速度更快，因为它仅使用单个票证即可访问多个网络资源。
很多安装最初都采用 NTLM 而不是 Kerberos，因为规划拓扑、服务器规模调整、安全支持提供程序 (SSP) 以及其他复杂细节已经令人望而生畏了，如果进一步提高复杂性，会让用户感到力不从心。这种看法有其合理之处。不管怎么说，启用了 Kerberos 的实现难免会出现问题。只要阅读知识库文章 871179、962943 和 832769，便可了解到可能出现的一些问题，这些问题可能同蓝屏 STOP 错误一样严重。即便是现有文档，例如 Microsoft 的 Kerberos 详细实现指南，也没有包括有关 IIS 版本 7 或更高版本的详细信息，这些版本实现了内核模式身份验证功能，并改变了处理 SPN 的方式。但不要担心，如果您了解 SharePoint 如何使用 Kerberos 的基本概念，则实现和配置 Kerberos 会变得相对简单一些。本文介绍了基本的体系结构组件，还包括一些配置详细信息，可以帮助您入门。Microsoft 已经发布了带有分步详细信息的文档，以及知识库文章 832769 和 953130，可为您提供更多参考。
身份验证组件和依赖关系
首先，我们将了解处理集成 Windows 身份验证的 SharePoint 体系结构中的依赖关系。从最基本的层面上来讲，无论是使用 NTLM 还是 Kerberos，都会有一个客户端向启用 SharePoint 的 .aspx 网页发出请求，该网页在后台使用 .NET 和 IIS。与此同时，该网页还依赖于 SQL Server 配置和内容数据库中的数据。图 1 显示了 IIS 如何在 SharePoint 2007 上下文中处理与身份验证相关的请求。当客户端浏览器发出 Web 请求时，将在 IIS 中启动一个线程，且与该请求相关的对象(例如，包含在 IPrincipal 对象中的 IIdentity 对象所含的令牌)将被附加到线程。从编程角度而言，IIdentity 和 IPrincipal 对象均通过 HttpContext.User 属性访问，而这两个对象和该属性均由 .NET 管道中包含的身份验证模块设置，如图 1 所示。
图 1 SharePoint 中的通用身份验证组件和数据流
以下流程详细说明了数据流：
1. 客户端浏览器通过匿名 HTTP GET 请求初始化与 SharePoint 前端服务器的连接(由带有 .NET 的 IIS 处理)。
2. 如果该区域配置了匿名访问(例如在 Internet 方案中)，则 IIS 将继续处理该请求。否则，IIS 将返回错误 401.2 并请求从客户端浏览器中进行身份验证。
3. 客户端浏览器接收请求，并根据区域和关联的选项对客户端进行身份验证。常用方法是调用 AcquireCredentialsHandle 并提示输入用户名/密码，然后通过 IIS 将身份验证令牌返回 SharePoint。
4. IIS 正在 HTTP 会话中等待响应并接受身份验证令牌，然后授权或拒绝访问。此时，IIS 通过 .NET 将请求传递给 SharePoint。
5. 如果请求的页面包含需要访问后端 SQL 数据库的 Web 部件，则 SharePoint 将进行 SQL Server 身份验证并访问数据库。SQL 身份验证的特性因配置选项而异。例如，您可以配置使用 NTLM 或 Kerberos 的 SQL Server 身份验证或集成 Windows 身份验证。下文将介绍 Kerberos 和 NTLM 的具体内容。
SharePoint 中身份验证机制的关键所在是以下三个层分别行使各自的功能：客户端浏览器、带有 .NET 的 IIS 以及 SQL Server。为了返回已编译的 .aspx 页，身份验证和授权都在客户端、IIS 和 SQL Server 之间进行。有时候这一流程也会简化，例如在 SQL Server 与 IIS 位于同一物理服务器中的情况下使用 NTLM 进行身份验证时。在这种情况下，从客户端到 IIS 只有一个跃点。有关 .NET 中的身份验证的详细信息，请参阅解释：ASP.NET 2.0 中的 Windows 身份验证。
