技术开发 频道

使用 Kerberos 进行SharePoint身份验证

    【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

  图 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 身份验证。

点击查看更多TechNet精彩文章

0
相关文章