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 身份验证的详细信息如下所示：
1. 流程按上文所述的方式开始，客户端浏览器利用 HTTP GET 请求来初始化与运行带有 .NET 的 IIS 的 SharePoint 前端服务器的连接，并尝试以匿名方式进行身份验证。
2. IIS 拒绝匿名请求，返回 401.2 错误，并发回使用 NTLM (WWW-Authenticate: NTLM) 进行身份验证的请求。
3. 客户端浏览器接收该请求，并调用 InitializeSecurityContext 以创建包含域和计算机名称的身份验证令牌，然后将该身份验证令牌发送到 IIS。
4. IIS 接受详细信息，并向客户端发送 NTLM 质询。
5. 客户端利用已用用户密码进行了加密的质询响应(即身份验证令牌)进行响应。
6. 此时，IIS 需要与域控制器会话。它发送客户端的用户名、质询和质询响应。
7. 域控制器检索用户的密码哈希，并将其与使用用户凭据加密的质询响应进行比较。如果两者匹配，域控制器将向 IIS 返回身份验证成功消息，IIS 可与客户端浏览器会话。
8. 此时，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 身份验证
1. 与 NTLM 相同，客户端浏览器使用主机名(FQDN 或别名)以匿名方式发出 HTTP GET 请求。
2. 前端服务器响应，返回 401.2 错误以及 WWW-Authenticate: Negotiate 头和/或 WWW-Authenticate: Kerberos 头(表明它支持 Kerberos 身份验证)。您必须在管理中心中显式配置前端服务器上的此设置，相关内容将在下文讨论。
3. 客户端与域控制器上的 KDC 联系，并基于浏览器客户端以主机名的形式发送的信息为 SPN 请求票证。
4. 如果 KDC 找到匹配的 SPN，它将对票证进行加密并将其返回。
5. 浏览器客户端创建身份验证器，并将其与服务票证一同发送到 IIS 服务器。随后，IIS 服务器对票证进行解密，确定身份，并检查其对所请求资源的权限(访问控制列表)，确定是否允许访问。
6. 如果允许访问，IIS 将通过 Web 应用程序服务联系 SQL Server，该服务将从 KDC 请求 SQL Server 票证。
7. 如果找到 SPN，KDC 将返回票证，Web 应用程序使用该票证来查询内容数据库，并通过委派模拟用户。
8. SQL Server 检查来自 Web 应用程序的票证，并验证该票证。验证成功后，SQL Server 将数据发送回服务器，.NET 将能够编译 aspx 页，并将其发送到浏览器。
