两种SharePoint 身份验证的选择：Kerberos .vs. NTLM_综合

虽然 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 中的通用身份验证组件和数据流

以下流程详细说明了数据流：

客户端浏览器通过匿名 HTTP GET 请求初始化与 SharePoint 前端服务器的连接（由带有 .NET 的 IIS 处理）。
如果该区域配置了匿名访问（例如在 Internet 方案中），则 IIS 将继续处理该请求。否则，IIS 将返回错误 401.2 并请求从客户端浏览器中进行身份验证。
客户端浏览器接收请求，并根据区域和关联的选项对客户端进行身份验证。常用方法是调用 AcquireCredentialsHandle 并提示输入用户名/密码，然后通过 IIS 将身份验证令牌返回 SharePoint。
IIS 正在 HTTP 会话中等待响应并接受身份验证令牌，然后授权或拒绝访问。此时，IIS 通过 .NET 将请求传递给 SharePoint。
如果请求的页面包含需要访问后端 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 身份验证。

NTLM 和 Kerberos

现在您已经了解了 Windows Server、IIS 和 .NET 用于对用户进行身份验证和授权的基础机制，下面我们将说明如何通过这种机制使用 NTLM 和 Kerberos 进行集成 Windows 身份验证。正如上文所述，NTLM 和 Kerberos 之间的关键差异在于：NTLM 使用质询/响应机制，在访问每个网络资源时都需要进行身份验证和授权；而 Kerberos 则使用票证系统，只需进行一次身份验证，然后通过委派进行授权。如果您不太明白这一差异，也不要担心，下面我将进行详细说明。图 2 说明了 SharePoint 在使用 NTLM 时如何处理请求。

图 2 SharePoint 中的 NTLM 身份验证

如图 2 所示，使用 NTLM 需要一个能够对用户进行身份验证的域控制器。如果域在本机模式下运行，则默认情况下必须在域控制器或另一个服务器上有一个全局编录。除了双跃点问题之外，这也是一个潜在的性能问题，因为在与域控制器取得联系之后，如果本地没有全局编录可用，则会通过代理将身份验证请求发送到全局编录服务器。在链路速度缓慢的情况下，这可能会消耗大量的资源和带宽。您可以想法设法提高 NTLM 身份验证的性能，例如通过更改 MaxConcurrentApi 注册表项的值，但这无法解决 NTLM 需要依赖质询/响应方案的根本需求，也无法解决高负载下的相关性能问题。

同一域中的帐户的 NTLM 身份验证的详细信息如下所示：

流程按上文所述的方式开始，客户端浏览器利用 HTTP GET 请求来初始化与运行带有 .NET 的 IIS 的 SharePoint 前端服务器的连接，并尝试以匿名方式进行身份验证。
IIS 拒绝匿名请求，返回 401.2 错误，并发回使用 NTLM (WWW-Authenticate: NTLM) 进行身份验证的请求。
客户端浏览器接收该请求，并调用 InitializeSecurityContext 以创建包含域和计算机名称的身份验证令牌，然后将该身份验证令牌发送到 IIS。
IIS 接受详细信息，并向客户端发送 NTLM 质询。
客户端利用已用用户密码进行了加密的质询响应（即身份验证令牌）进行响应。
此时，IIS 需要与域控制器会话。它发送客户端的用户名、质询和质询响应。
域控制器检索用户的密码哈希，并将其与使用用户凭据加密的质询响应进行比较。如果两者匹配，域控制器将向 IIS 返回身份验证成功消息，IIS 可与客户端浏览器会话。
此时，Web 应用程序将向 SQL Server 进行身份验证，可以访问包含 .aspx 页数据的内容数据库。

如果您曾经尝试在“管理中心”网页上为基本安装配置 Kerberos，那么您便知道，如果选择 Kerberos 而不是 NTLM，生成的消息将提示您配置应用程序池帐户以明确允许使用 Kerberos，除非应用程序池正在网络服务上下文中运行。这是因为基于 Kerberos 的身份验证的工作方式需要 SPN。在 WSS 和 MOSS 中，Web 应用程序实际上是分配给应用程序池的 IIS 网站，在内置或用户帐户上下文中运行。可以为同一应用程序池分配多个网站，但这并不是最佳做法。除非您进行更改，否则 IIS 会将网络服务帐户用于应用程序池，而不使用唯一域帐户。但是，若要在 SharePoint 中使用 Kerberos，必须针对应用程序池帐户设置唯一 SPN。

在实践中，基于 Kerberos 的通信必须具有一个客户端、一个能够支持 Kerberos 的服务器以及充当中间授权方的 KDC，此外还需要 SPN。技术细节稍微有些复杂。例如，Kerberos 还要求 DNS 与 Active Directory 或带有 SRV 记录、TCP/IP 和时间服务的 BIND 集成。如果您使用的是集成了 DNS 的 Windows Server 2003 或 2008，则您已经拥有了必需组件，只需配置这些组件即可。图 3 显示了 SharePoint 中基于 Kerberos 的身份验证所涉及的各个组件以及数据流。

图 3 Kerberos 身份验证

与 NTLM 相同，客户端浏览器使用主机名（FQDN 或别名）以匿名方式发出 HTTP GET 请求。
前端服务器响应，返回 401.2 错误以及 WWW-Authenticate: Negotiate 头和/或 WWW-Authenticate: Kerberos 头（表明它支持 Kerberos 身份验证）。您必须在管理中心中显式配置前端服务器上的此设置，相关内容将在下文讨论。
客户端与域控制器上的 KDC 联系，并基于浏览器客户端以主机名的形式发送的信息为 SPN 请求票证。
如果 KDC 找到匹配的 SPN，它将对票证进行加密并将其返回。
浏览器客户端创建身份验证器，并将其与服务票证一同发送到 IIS 服务器。随后，IIS 服务器对票证进行解密，确定身份，并检查其对所请求资源的权限（访问控制列表），确定是否允许访问。
如果允许访问，IIS 将通过 Web 应用程序服务联系 SQL Server，该服务将从 KDC 请求 SQL Server 票证。
如果找到 SPN，KDC 将返回票证，Web 应用程序使用该票证来查询内容数据库，并通过委派模拟用户。
SQL Server 检查来自 Web 应用程序的票证，并验证该票证。验证成功后，SQL Server 将数据发送回服务器，.NET 将能够编译 aspx 页，并将其发送到浏览器。

了解 SPN

SPN 是 Kerberos 配置中难度较大的环节之一，因为它们要作为被授权访问特定服务器资源的客户端资源的唯一标识符注册到 KDC。在集成 Windows 身份验证中，客户端和服务器必定信任 KDC，因为在几乎所有情况下，KDC 还是域控制器，它需要一种方法来确定是否为请求授予票证，这种方法就是 SPN。正如上文所述，当您为应用程序池设置域用户帐户时，还必须针对帐户设置 SPN，以便让所有人都能访问与应用程序池关联的 Web 应用程序。

SPN 是在服务器上运行的服务的唯一标识符字符串。它存储在 Active Directory 中用户帐户的名为 Service-Principal-Name 的多值属性中。一台主机或多台主机上的多项服务可以根据它们的唯一 SPN 进行区分。也许我过分强调了 SPN 的重要性，但这样做是有充分理由的。配置不当的 SPN 会破坏 Kerberos 身份验证。如果您设置了两个相同的 SPN，或者忘记设置 SPN，或者错误配置了 SPN 的某一部分，则身份验证将无法正常进行。

让我们来看一个 SPN 示例，以了解 Kerberos 如何使用 SPN。SPN 包括三个部分：标识服务类型的服务类、运行服务的主机的计算机名称、端口。这几个部分组合在一起，语法为：服务类/主机:端口。对于 SharePoint，有两个相关名称是 HTTP 和 MSSqlSvc。这两个服务名称不是任意的，而是定义为服务的特定别名。主机名部分是 FQDN 或 NetBIOS 名称，可以选择是否包括端口。注册 SPN 时，最佳做法是同时为 NetBIOS 和 FQDN 主机名注册 SPN，以便无论客户端使用什么方法，它们都可以访问目标主机上的资源。

在上文中，我曾提到除非在网络服务帐户下运行应用程序池，否则就需要显式注册 SPN。这是因为当计算机加入到 Active Directory 域时，将自动为计算机帐户创建 SPN，其格式为 HOST/<NetBIOSname> 和 HOST/<FQDN>。由于网络服务帐户作为网络上的一台计算机，因此 SPN 对它有效。但是，出于安全考虑，再加上本地帐户可能会破坏某些方案，因此使用本地网络服务帐户并不是最佳做法。例如，如果您要还原或附加使用网络服务帐户配置的内容数据库，则必须将该帐户添加到 SQL Server 上的本地管理员组，在附加数据库之后再将其删除。大多数现有文档推荐使用域帐户。

后端配置

无论您是从现有场迁移，还是安装新场，您都必须首先在 SQL Server 上配置 Kerberos 身份验证。SQL Server 必须满足上文所述的要求，例如加入到域、可以访问充当 KDC 的域控制器等。对于大多数环境而言，当使用集成了 DNS 的 Active Directory 时，在默认情况下可以满足这些要求。如果您的环境仅使用前端 SharePoint 服务器，而没有使用应用程序服务器（例如运行 Excel Services 或 SQL Reporting Services 的服务器），则不需要显式配置 Kerberos。对于基本的前端/后端连接，在 SQL Server 加入到域时创建的默认 SPN 足以满足要求。

在 SQL Server 上，配置 Kerberos 相对比较简单。首先，您要设置相关 SPN，然后验证使用的是否是 Kerberos 而不是默认的 NTLM。您应该设置 NetBIOS 名称和 FQDN，格式为 MSSQLSvc/<NetBIOS_Name>:1433 和 MSSQLSvc//<FQDN-hostname.domain.local>:1433，此处假定您的实例使用默认的 1433 端口。虽然您可以使用 setspn 工具或 ADSIEdit 来设置 SPN，但 setspn 通常是更好的选择，因为它可以验证输入的语法，以确保输入正确。相反，使用 ADSIEdit 时，您要直接将 SPN 写入 servicePrincipalName 属性。若要创建两个 SPN，请运行setspn-A MSSQLSvc/<NetBIOS_Name>:1433 <domain>/<username> 和 setspn-A MSSQLSvc/<FQDNe>:1433 <domain>/<username>，其中用户名为 SQL Server 服务帐户。

若要确认 SQL Server 流量使用的是 Kerberos，您可以使用 Wireshark 等数据包分析器跟踪流量，也可以使用 Kerbtray.exe 等工具，或者检查事件日志。如果您使用 SQL Server Management Studio 连接到 SQL 实例，则安全事件日志将显示事件 ID 540，其中的登录进程和身份验证数据包使用 Kerberos。有关详细信息，请参阅为 SQL 通信配置 Kerberos 身份验证。

前端和应用程序服务器配置

确保 Kerberos 在 SQL Server 中正常工作后，接下来您可以配置 SharePoint，包括为应用程序池设置 SPN，为 SSP 和 Web 应用程序启用 Kerberos，并完成一些最终配置步骤。SPN 配置类似于 SQL Server 服务帐户的配置，但需要配置更多的 SPN。回顾一下，SPN 是基于用户在客户端浏览器地址栏中输入的地址构造的，因此您必须为用户可能在地址栏中输入以访问网站的每个条目设置 SPN。这包括采用主机头格式的 FQDN、NetBIOS 名称和别名。图 4 列出了资源类型示例以及需要为每个资源类型注册的 SPN。

图 4 基本 MOSS 场的 SPN

在设置 SPN 时，应该记住一些注意事项。首先，SPN 要注册到启用 SharePoint 的网站，正如要注册到任何 IIS 网站那样。重要的是指定正确的主机名和帐户，每个网站的应用程序池在该帐户下运行。如果使用多个主机头，请确保为所有主机头设置 SPN。第二，不需要指定 HTTP 和 HTTPS 端口，但应该指定任何自定义端口。第三，您可能还需要配置其他一些依赖关系，例如配置针对 IIS 的注册表更改以支持带有自定义端口的 SPN 格式，以及配置更新以支持 SSP。您可以在配置 Kerberos 身份验证 (Office SharePoint Server) 中找到更多详细信息。

若想让 Kerberos 在环境中正常工作，您还应该完成另外两个重要步骤。您必须配置用于委派的计算机帐户和一些服务帐户，还必须在管理中心为 Kerberos 配置场。Kerberos 中的委派的原理是：如果用户向最终资源发出请求，则一些中介帐户必须处理该请求，这些中介帐户是可信任的，能够代表用户进行委派。可以将 Active Directory 用户和计算机作为域管理员，从而来配置用于委派的帐户。在用户或计算机帐户的“委派”选项卡下，选择“信任此用户/计算机来委派任何服务(Kerberos)”。您应该为前端、应用程序和 SQL Server 计算机帐户启用委派，还应为应用程序池（SSPAdmin、MySite、各种 Web 应用程序）和场服务帐户启用委派。

此外，您还需要在“组件服务”中设置权限。在默认属性下，将“模拟级别”设置为“委派”。在“IIS WAMREG Admin Service”下，定位到“安全”选项卡，为应用程序池帐户授予“本地激活”权限。有关详细信息，请参阅知识库文章 917409 和 920783。

启用委派后，即可通过启用 Kerberos 作为 SSP 和 Web 应用程序的首选协议来完成具体的配置工作。对于新安装，可以在 SharePoint 产品和技术配置向导中为管理中心网站进行此操作。否则，请在管理中心的“应用程序管理”下定位到“验证提供程序”，单击“默认值”并将方法设置为“协商(Kerberos)”。不要忘记运行 iisreset /noforce，将更改应用于应用程序池，并为 SSP 启用 Kerberos。

IIS 7 和 Windows Server 2008 中的变化

截止目前，我们讨论的内容主要限于 Windows Server 2003 和 IIS 6 上的 SharePoint 2007。如果您迁移到 Windows Server 2008 和 IIS 7，则在体系结构上有一些变化，可能需要其他一些配置步骤。IIS 7 中的最显著变化也许是它支持内核模式 Kerberos 身份验证。在内核模式身份验证中，网络服务帐户（实际上就是上文所述的计算机帐户）将对票证进行解密，除非您指定了其他设置。当您迁移到 IIS 7 或安装一个新场时，默认情况下将启用内核模式身份验证。正如上文所述，网络服务帐户是本地帐户。如果运行的是单个服务器，则解密可以正常进行。但在场中，解密会失败，因为您需要使用可以通过 KDC 验证的域帐户。这一变化还意味着您可以使用网络服务帐户进行协议转换（允许客户端向 IIS 进行非 Kerberos 身份验证，允许 IIS 将 Kerberos 用于后端通信），因为该帐户已经具有 LocalSystem 权限。

若要在运行 IIS 7 的 SharePoint 场中配置 Kerberos，需要手动更改 %WinDir%/System32/inetsrv/config/ApplicationHost.config 文件 — 当前没有 GUI 选项。相关条目如下所示。

<system.webServer> <security> <authentication> <windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true" /> </authentication> </security> </system.webServer>

不要忘记运行 iisreset /noforce 以应用更改，并检查最新更新以发现问题，例如在知识库文章 962943 中详细说明的蓝屏更新。

如果您的配置使用了身份模拟（web.config 中的 <identity impersonate="true" />）和集成模式管道，则还应注意另外一个配置细节。在此情况下，需要将 validateIntegratedModeConfiguration 设置为 false，或在经典模式管道中运行 .aspx 页。

结论

虽然 Kerberos 身份验证需要一些额外配置步骤，还需要 NTLM 之外的更多知识，但目前的趋势是向 Kerberos 迁移。Microsoft 在 II7 中将 Kerberos 作为默认选中选项，并且为 Kerberos 提供了良好的支持，因为它是一个开放的标准。使用 Kerberos 物有所值。现在有大量文档介绍 Kerberos 的部署、验证和故障排除，这也为我们实际使用 Kerberos 提供了支持。您无需进行很多更改即可避免由于过多身份验证跃点而导致的性能下降问题，享受 Kerberos 的良好安全性。

Pav Cherny 是一位 IT 专家兼撰稿人，专门研究 Microsoft 协作与统一通信技术。他的出版物包括白皮书、产品手册和书籍，其内容主要介绍 IT 运营和系统管理。同时，Pav 还是 Biblioso Corporation 的总裁，该公司主要经营托管文档和本地化服务。

两种SharePoint 身份验证的选择：Kerberos .vs. NTLM