Microsoft SharePoint 2010 产品的 Kerberos 身份验证概述

 

适用于： SharePoint Server 2010

上一次修改主题： 2016-11-30

Microsoft SharePoint 2010 产品大大改进了在平台中管理标识的方法。若要实现需要将用户标识委派给集成系统的方案，则必须了解这些更改如何影响解决方案设计和平台配置。Kerberos 版本 5 协议在启用委派方面扮演重要角色，在这些方案中有时可能会需要该协议。

此组文章提供了可帮助您执行以下操作的信息：

• 了解 SharePoint 2010 产品中的标识的概念

• 了解 Kerberos 身份验证如何在身份验证和委派方案中扮演非常重要的角色

• 识别应利用 Kerberos 身份验证或解决方案设计中可能需要 Kerberos 身份验证的情形

• 在您的环境中配置端到端 Kerberos 身份验证，包括使用 SharePoint Server 中的各种服务应用程序的情形

• 测试和验证 Kerberos 身份验证的配置是否正确以及是否正常工作

• 查找其他工具和资源来帮助您在环境中配置 Kerberos 身份验证

此组文章主要分为两部分：

• SharePoint 2010 产品中的 Kerberos 身份验证概述（本部分）

  本文包含有关如何管理 SharePoint 2010 产品中的标识、Kerberos 协议以及 Kerberos 身份验证如何在 SharePoint 2010 解决方案中扮演重要角色的概念信息。

• 分步配置

  这组文章讨论在各种 SharePoint 解决方案情形中配置 Kerberos 身份验证和委派所需的步骤。

哪些人应阅读这些 Kerberos 身份验证文章？

SharePoint 2010 产品中的标识和委派是一个宽泛的主题，可从许多方面和深度进行理解。这组文章从概念和技术层面上讨论此主题，并用于满足各种受众的需要：

从头到尾

“告诉我需要了解的有关 SharePoint 2010 产品中的标识和 Kerberos 身份验证的所有内容”

如果您刚刚开始了解 SharePoint 2010 产品、Kerberos 身份验证和声明身份验证，则需要阅读本文档的第一部分。它涵盖了标识和委派的基本概念，并提供了有关声明和 Kerberos 身份验证的入门知识。确保打开指向外部文章及其他信息的链接来积累扎实的知识基础，然后再继续阅读分步配置文章。

从 Office SharePoint Server 2007 升级

“告诉我与 2007 相比有何变化以及应如何准备升级到 2010”

如果您已将现有 Microsoft Office SharePoint Server 2007 环境配置为使用 Kerberos 身份验证和 Kerberos 委派，则应阅读以下文章：

• SharePoint 2010 产品中的标识方案

• 声明入门知识

• Windows 2008 R2 和 Windows 7 中的 Kerberos 身份验证更改

• SharePoint 2010 产品中的 Kerberos 配置更改

• 从 SharePoint Server 2007 升级时的注意事项

如果您有其他有关如何为特定功能或方案配置委派的问题，请阅读分步配置文章，尤其是配置清单。这将帮助您确保环境在升级后得到正确配置。

分步演练

“我需要有关如何在 SharePoint Server 及适用的 SharePoint Server 服务应用程序中配置 Kerberos 委派的详细分步说明”

分步配置文章涵盖多个可配置为使用 Kerberos 委派的 SharePoint 2010 产品方案。其中详细介绍了每个方案，包括配置清单和分步说明，以帮助您成功地在环境中配置 Kerberos 身份验证。涵盖的方案包括：

• 方案 1：核心配置

• 方案 2：SQL OLTP 的 Kerberos 身份验证

• 方案 3：SQL Analysis Services 的 Kerberos 身份验证

• 方案 4：SQL Reporting Services 的标识委派

• 方案 5：Excel Services 的标识委派

• 方案 6：PowerPivot for SharePoint 2010 的标识委派

• 方案 7：Visio Services 的标识委派

• 方案 8：PerformancePoint Services 的标识委派

• 方案 9：Business Connectivity Services 的标识委派

确保详细查看第一个核心配置方案，因为它是后面的所有方案的先决条件。

备注

这些方案包括您可能选择从本文档复制并粘贴到命令提示符窗口中的“SetSPN”命令。这些命令包括连字符。Microsoft Word 具有自动套用格式功能，该功能往往会将连字符转换为短划线字符。如果您在 Word 中启用了该功能，然后执行复制粘贴操作，则命令将不会正确运行。将短划线更改为连字符可修复此错误。若要在 Word 中禁用该自动套用格式功能，请从“文件”菜单中选择“选项”，单击“校对”选项卡，然后打开“自动更正”对话框。

现有的 SharePoint 2010 产品环境

“我已经有 SharePoint 2010 产品环境，但我好像无法运行 Kerberos 身份验证。如何验证和调试我的配置？”

分步配置文章包含多个清单来帮助在各种方案中会审您的环境。请特别注意方案 1 核心配置，其中包括用于会审 Kerberos 配置的基本工具和技术。

SharePoint 2010 产品中的标识方案

在了解了 SharePoint 2010 产品中的身份验证上下文中的标识后，您可以从概念上查看在三个关键方案中平台如何处理标识：传入身份验证、服务器场间/服务器场内身份验证和传出身份验证。

传入标识

传入身份验证方案表示客户端向平台呈现其标识（或换句话说，向 Web 应用程序或 Web 服务进行身份验证）的方法。SharePoint Server 将使用客户端的标识来授权客户端访问 SharePoint Server 安全资源，例如网页、文档等。

SharePoint 2010 产品支持客户端通过两种方式向平台进行身份验证：经典模式和声明模式。

经典模式

经典模式允许您使用典型 Internet Information Services (IIS) 身份验证方法，在以前版本的 SharePoint Server 中您可能已经熟悉这些方法。当 SharePoint Server 2010 Web 应用程序配置为使用经典模式时，您可以选择使用以下 IIS 身份验证方法：

集成 Windows 身份验证

利用集成 Windows 身份验证，Windows 客户端可以向 SharePoint Server 进行无缝身份验证，而不必手动提供凭据（用户名/密码）。从 Internet Explorer 访问 SharePoint Server 的用户将通过使用 Internet Explorer 进程运行时所采用的凭据进行身份验证 — 默认为用户用于登录到桌面的凭据。以 Windows 集成模式访问 SharePoint Server 的服务或应用程序将尝试使用正在运行的线程的凭据进行身份验证，默认情况下该凭据是进程的标识。

NTLM

NT LAN Manager (NTLM) 是选择集成 Windows 身份验证时的默认协议类型。此协议利用由三部分组成的质询响应序列来对客户端进行身份验证。有关 NTLM 的详细信息，请参阅 Microsoft NTLM（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=196643&clcid=0x804)（该链接可能指向英文页面）。

优点：

• 易于配置，并且通常无需其他基础结构/环境配置即可运行

• 它适用于客户端不是域的一部分或不在受 SharePoint Server 驻留的域所信任的域中的情况

缺点：

• 每次客户端身份验证响应需要验证时，它都要求 SharePoint Server 联系域控制器，从而增加了通往域控制器的流量。

• 它不允许将客户端凭据委派给后端系统，即所谓的双跃点规则。

• 它是专用协议。

• 它不支持服务器身份验证。

• 它的安全性没有 Kerberos 身份验证那么高

Kerberos 协议

Kerberos 协议是一种支持票证身份验证的更安全的协议。如果客户端计算机的身份验证请求包含有效的用户凭据和有效的服务主体名称 (SPN)，则 Kerberos 身份验证服务器将授予一个票证以响应该请求。然后，客户端计算机使用该票证来访问网络资源。若要启用 Kerberos 身份验证，客户端和服务器计算机必须建立到域密钥发行中心 (KDC) 的受信任连接。KDC 发行共享密钥以启用加密。客户端和服务器计算机还必须能够访问 Active Directory 目录服务。对于 Active Directory，目录林根级域是 Kerberos 身份验证检索的中心。有关 Kerberos 协议的详细信息，请参阅 Kerberos 版本 5 身份验证协议如何工作（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=196644&clcid=0x804)（该链接可能指向英文页面） 和 Microsoft Kerberos（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=196645&clcid=0x804)（该链接可能指向英文页面）。

优点：

• 最安全的集成 Windows 身份验证协议

• 允许委派客户端凭据

• 支持客户端和服务器的相互身份验证

• 产生较少的通往域控制器的流量

• 受许多平台和供应商支持的开放式协议

缺点：

• 需要对基础结构和环境进行进一步配置才能正确运行

• 需要客户端通过 TCP/UDP 端口 88 (Kerberos) 和 TCP/UDP 端口 464（Kerberos 更改密码 – Windows）连接到 KDC（Windows 环境中的 Active Directory 域控制器）

其他方法

除了 NTLM 和 Kerberos 身份验证外，SharePoint Server 还支持其他种类的 IIS 身份验证，例如基本身份验证、摘要式身份验证和基于证书的身份验证，本文档不讨论这些身份验证。有关这些协议如何发挥作用的详细信息，请参阅 IIS 6.0 中支持的身份验证方法 (IIS 6.0)（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=196646&clcid=0x804)（该链接可能指向英文页面）。

基于声明的身份验证

支持声明身份验证是 SharePoint 2010 产品中的一项新功能，它基于 Windows Identity Foundation (WIF) 构建。在声明模型中，SharePoint Server 接受一个或多个有关进行身份验证的客户端的声明，以识别和授权该客户端。声明以 SAML 令牌的形式出现，是由受信任的颁发机构陈述的有关客户端的事实。例如，声明可能指出“Bob is a member of the Enterprise Admins group for the domain Contoso.com”（Bob 是域 Contoso.com 的企业管理员组的成员）。如果此声明来自 SharePoint Server 信任的提供程序，则平台可以使用此信息对 Bob 进行身份验证并授权他访问 SharePoint Server 资源。有关声明身份验证的详细信息，请参阅基于声明的标识和访问控制指南（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=187911&clcid=0x804)（该链接可能指向英文页面）。

SharePoint 2010 产品支持的传入身份验证的声明种类是 Windows 声明、基于表单的身份验证声明和 SAML 声明。

Windows 声明

在 Windows 声明模式登录过程中，SharePoint Server 使用标准集成 Windows 身份验证 (NTLM/Kerberos) 对客户端进行身份验证，然后将生成的 Windows 标识转换为声明标识。

基于表单的身份验证声明

在基于表单的身份验证声明模式中，SharePoint Server 将客户端重定向到包含标准 ASP.NET 登录控件的登录页。该页使用 ASP.NET 成员资格和角色提供程序对客户端进行身份验证，这类似于基于表单的身份验证在 Office SharePoint Server 2007 中的工作方式。在创建了代表用户的标识对象后，SharePoint Server 将此标识转换为声明标识对象。

SAML 声明

在 SAML 声明模式中，SharePoint Server 从受信任的外部安全令牌提供程序 (STS) 接受 SAML 令牌。当用户尝试登录时，“参阅注释”将被定向到对用户进行身份验证并生成 SAML 令牌的外部声明提供程序（例如，Windows Live ID 声明提供程序）。SharePoint Server 接受并处理此令牌，从而扩充声明并为用户创建声明标识对象。

有关 SharePoint 2010 产品中的基于声明的身份验证的详细信息，请参阅 SharePoint 基于声明的标识。

有关传入声明身份验证和声明为 Windows 令牌服务 (C2WTS) 的注释

有些服务应用程序要求您使用 Windows Identity Foundation (WIF) 声明为 Windows 令牌服务 (C2WTS) 将服务器场中的声明转换为 Windows 凭据来进行出站身份验证。必须了解，仅当传入身份验证方法是基本模式或 Windows 声明时，C2WTS 才能运行。如果配置了声明，则 C2WTS 仅要求 Windows 声明；Web 应用程序不能使用多种形式的声明，否则 C2WTS 不会运行。

SharePoint 2010 产品环境中的标识

SharePoint 2010 产品环境使用声明身份验证与大多数 SharePoint 服务应用程序和 SharePoint 集成产品进行服务器场内和服务器场间的通信，而不考虑使用的传入身份验证机制。这意味着即使使用经典身份验证向特定 Web 应用程序进行身份验证，SharePoint 产品也会将传入标识转换为声明标识来向声明感知 SharePoint 服务应用程序和产品进行身份验证。通过标准化服务器场内/服务器场间通信的声明模型，平台可以根据使用的传入协议将自身抽象化。

备注

一些与 SharePoint Server 集成的产品（例如 SQL Server Reporting Services）不是声明感知产品，并且没有利用服务器场内声明身份验证体系结构。在其他方案中，SharePoint Server 可能还依赖经典 Kerberos 委派和声明，例如，当 RSS 查看器 Web 部件配置为使用已验证源时。请参阅每种产品或服务应用程序的文档，确定它是否支持基于声明的身份验证和标识委派。

出站标识

SharePoint 2010 产品中的出站标识表示服务器场中的服务必须向外部业务线系统和服务进行身份验证的情形。根据情形的不同，可以采用两种基本概念模型之一执行身份验证：

受信任的子系统

在受信任的子系统中，前端服务先对客户端进行身份验证和授权，然后向其他后端服务进行身份验证，但不会将客户端标识传递到后端系统。后端系统信任 前端服务代表它来执行身份验证和授权。实现此模型的最常见方法是使用共享服务帐户向外部系统进行身份验证：

在 SharePoint Server 中，可以采用多种方法实现此模型：

• 使用 IIS 应用程序池标识 — 通常通过在调用外部系统时提升权限的 Web 应用程序中运行代码来实现。其他方法（例如使用 RevertToSelf）也可使用应用程序池的标识向外部系统进行身份验证。

• 使用服务帐户 — 通常通过将应用程序凭据存储在安全存储中，然后使用这些凭据向外部系统进行身份验证来实现。其他方法包括以其他方式（例如嵌入连接字符串）存储服务帐户凭据。

• 匿名身份验证 — 这是外部系统无需任何身份验证的情况。因此，前端 SharePoint Server 服务不必将任何标识传递给后端系统。

委派

在委派模型中，前端服务首先对客户端进行身份验证，然后使用客户端的标识向另一个执行自己的身份验证和授权的后端系统进行身份验证：

在 SharePoint 2010 产品 中，可以采用多种方法实现此模型：

• Kerberos 委派 — 如果客户端使用 Kerberos 身份验证向前端服务进行身份验证，则 Kerberos 委派可用于将客户端的标识传递给后端系统。

• 声明 — 声明身份验证允许在服务之间传递客户端的声明，只要两种服务之间存在信任并且两种服务都是声明感知服务即可。

备注

目前，SharePoint Server 附带的大多数服务应用程序不允许出站声明身份验证，但出站声明是以后将会加以利用的一项平台功能。此外，如今许多最常用的业务线系统不支持传入声明身份验证，这意味着可能无法使用出站声明身份验证，或者需要进一步开发才能正确使用。

跨域和林边界的委派

这组介绍 Kerberos 身份验证的文章中的方案要求 SharePoint Server 服务和外部数据源驻留在同一 Windows 域中，这是 Kerberos 约束委派所必需的。Kerberos 协议支持两种委派：基本（非约束）和约束。基本 Kerberos 委派可以跨越单个林中的域边界，但不能跨越林边界，无论存在哪种信任关系。在任何方案中，Kerberos 约束委派都不能跨越域或林边界。

一些 SharePoint Server 服务可配置为使用基本 Kerberos 委派，但其他服务要求您使用约束委派。依赖声明为 Windows 令牌服务 (C2WTS) 的任何服务都必须使用 Kerberos 约束委派，才能允许 C2WTS 使用 Kerberos 协议转换将声明转换为 Windows 凭据。

以下服务应用程序和产品要求 C2WTS 和 Kerberos 约束委派：

• Excel Services

• PerformancePoint Services

• InfoPath Forms Services

• Visio Services

以下服务应用程序和产品不受这些要求的影响，因此可以在需要时使用基本委派：

• Business Data Connectivity Service 和 Microsoft Business Connectivity Services

• Access Services

• Microsoft SQL Server Reporting Services (SSRS)

• Microsoft Project Server 2010

以下服务应用程序不允许委派客户端凭据，因此不受这些要求的影响：

• Microsoft SQL Server PowerPivot for Microsoft SharePoint

声明入门知识

有关声明概念和基于声明的身份验证的简介，请参阅声明简介（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=196648&clcid=0x804)（该链接可能指向英文页面） 和 SharePoint 基于声明的标识 (https://go.microsoft.com/fwlink/?linkid=196647&clcid=0x804)。

Kerberos 协议入门知识

有关 Kerberos 协议的概念性概述，请参阅 Microsoft Kerberos (Windows)（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=196645&clcid=0x804)（该链接可能指向英文页面）、Kerberos 介绍（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=196649&clcid=0x804)（该链接可能指向英文页面） 和询问目录服务团队：用于忙碌的管理员的 Kerberos（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=196650&clcid=0x804)（该链接可能指向英文页面）。

Kerberos 协议的好处

在查看如何配置 SharePoint Server（或任何 Web 应用程序）以使用 Kerberos 协议的详细信息之前，让我们概括地谈谈 Kerberos 协议和可能需要使用它的原因。

使用 Kerberos 协议通常有三个主要原因：

1. 委派客户端凭据 — Kerberos 协议允许服务模拟客户端的标识，以允许模拟服务代表客户端将该标识传递给其他网络服务。NTLM 不允许此委派。（此限制 NTLM 称为“双跃点规则”）。声明身份验证（如 Kerberos 身份验证）可用于委派客户端凭据，但要求后端应用程序是声明感知应用程序。

2. 安全性 — AES 加密、相互身份验证、数据完整性和数据隐私支持等功能使 Kerberos 协议比对应的 NTLM 更安全。

3. 潜在的性能改进 — 与 NTLM 相比，Kerberos 身份验证需要较少的通往域控制器的流量（根据 PAC 验证，请参阅 Microsoft 开放式规范支持团队博客：了解 Microsoft Kerberos PAC 验证（该链接可能指向英文页面））。如果禁用了或不需要 PAC 验证，则对客户端进行身份验证的服务不必对 DC 进行 RPC 调用（请参阅：在 Windows 2000 或 Windows Server 2003 中的域成员上运行大容量服务器程序时，用户身份验证过程中出现延迟）。与 NTLM 相比，Kerberos 身份验证还需要较少的客户端和服务器之间的流量。客户端可以通过两次请求/响应向 Web 服务器进行身份验证，而 NTLM 采用典型的三次握手。不过，在低延迟网络上的每个事务中，这种改进通常并不明显，但总体系统吞吐量中的这种改进通常非常明显。请注意，许多环境因素都会影响身份验证性能；因此应在您自己的环境中对 Kerberos 身份验证和 NTLM 进行测试性能，然后才能确定哪种方法效果更好。

下面列出了使用 Kerberos 协议的部分好处。使用 Kerberos 协议的其他原因包括相互身份验证、跨平台互操作性和可传递跨域信任等。不过，大多数情况下，委派和安全性通常是采用 Kerberos 协议的主要原因。

Kerberos 委派、约束委派和协议转换

Windows 平台上的 Kerberos 版本 5 协议支持两种标识委派：基本（非约束）委派和约束委派。

类型	优点	缺点
基本委派	可以跨越单个林中的域边界 需要的配置工作比约束委派少。	不支持协议转换 安全。如果前端服务受到威胁，则可以将客户端标识委派给林中接受 Kerberos 身份验证的任何服务。
约束委派	可以将非 Kerberos 传入身份验证协议转换为 Kerberos（示例：NTLM 转换为 Kerberos，声明转换为 Kerberos） 更安全。只能将标识委派给指定服务。	不能跨越域边界 需要更多安装配置

启用了 Kerberos 的服务可以跨多个服务和多个跃点多次委派标识。当标识在服务之间传递时，委派方法可以从基本更改为约束，但不能从约束改为基本。这是一个必须了解的重要设计细节：如果后端服务需要基本委派（例如要跨域边界委派），则后端服务前面的所有服务都必须使用基本委派。如果任何前端服务使用约束委派，则后端服务无法将约束令牌更改为非约束令牌来跨越域边界。

协议转换允许启用了 Kerberos 的身份验证服务（前端服务）将非 Kerberos 标识转换为 Kerberos 标识，然后可以将 Kerberos 标识委派给其他启用了 Kerberos 的服务（后端服务）。协议转换需要 Kerberos 约束委派，因此协议经过转换的标识不能跨越域边界。根据前端服务的用户权限，协议转换返回的 Kerberos 票证可以是标识令牌或模拟令牌。有关约束委派和协议转换的详细信息，请参阅以下文章：

• Kerberos 协议转换和约束委派（该链接可能指向英文页面） (https://technet.microsoft.com/zh-cn/library/cc739587(WS.10).aspx)（该链接可能指向英文页面）

• 协议转换与约束委派技术补充材料（该链接可能指向英文页面） (https://msdn.microsoft.com/zh-cn/library/ff650469.aspx)（该链接可能指向英文页面）

• 多跃点方案中 Kerberos 约束委派可能需要协议转换（该链接可能指向英文页面） (https://support.microsoft.com/kb/2005838/zh-cn)（该链接可能指向英文页面）

作为一般的最佳实践，如果需要 Kerberos 委派，则应在可能的情况下使用约束委派。如果需要跨域边界的委派，则委派路径中的所有服务都必须使用基本委派。

Windows 2008 R2 和 Windows 7 中的 Kerberos 身份验证更改

Windows Server 2008 R2 和 Windows 7 引入了 Kerberos 身份验证的新功能。有关更改的概述，请参阅 Kerberos 身份验证中的变化 (https://go.microsoft.com/fwlink/?linkid=196655&clcid=0x804) 和 Kerberos 增强功能（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=196656&clcid=0x804)（该链接可能指向英文页面）。此外，您还应熟悉 IIS 7.0 内核模式身份验证（Internet Information Services (IIS) 7.0 内核模式身份验证设置（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=196657&clcid=0x804)（该链接可能指向英文页面）），即使它在 SharePoint Server 场中不受支持。

SharePoint 2010 产品中的 Kerberos 配置更改

SharePoint 2010 产品中用于配置 Kerberos 身份验证的大多数基本概念没有变化。您仍必须配置服务主体名称，并且仍必须配置计算机和服务帐户上的委派设置。不过，您应了解几项变化：

• 约束委派 — 使用声明为 Windows 令牌服务的服务所必需的。必须使用约束委派才能允许协议转换将声明转换为 Windows 令牌。

• 服务应用程序 — 在 Office SharePoint Server 2007 中，SSP 服务需要特殊的 SPN 和服务器注册表更改才能启用委派。在 SharePoint 2010 产品中，服务应用程序使用声明身份验证和声明为 Windows 令牌服务，因此不再需要这些更改。

• Windows Identity Foundation (WIF) — WIF 声明为 Windows 令牌服务 (C2WTS) 是 SharePoint 2010 产品利用的一项新服务，用于针对委派方案将声明转换为 Windows 令牌。

从 Office SharePoint Server 2007 升级时的注意事项

如果将 Office SharePoint Server 2007 场升级到 SharePoint Server 2010，则在完成升级时应考虑以下多个事项：

• 如果 Web 应用程序将更改 URL，请确保更新服务主体名称以反映 DNS 名称。

• 删除 SSP 服务主体名称，因为 SharePoint Server 2010 中不再需要它们。

• 启动运行需要委派的服务应用程序的服务器上的声明为 Windows 令牌服务（例如 Excel Services、Visio Graphics Service）。

• 使用“使用任何身份验证协议”配置 Kerberos 约束委派，以允许使用 C2WTS 的 Kerberos 约束委派。

• 确保 IIS 中禁用了内核模式身份验证。