使用 Microsoft Edge 进行 Kerberos 不受约束的双跃点身份验证（Chromium）

适用于： Internet Information Services

简介

根据 Kerberos 身份验证协议设置 Windows 身份验证可能是一项复杂的工作，尤其是在处理从前端站点委托标识到 IIS 上下文中的后端服务以及 ASP.NET 等方案时。 按照本文的步骤设置身份验证票证委派，并将服务与新式浏览器（如 Microsoft Edge 版本 87 或更高版本）配合使用。

本文假定你设置的体系结构类似于下图中所示的体系结构：

• Workstation-Client1 计算机是主 Web 服务器（称为 Primary-IIS-SRV）和后端 Web 服务器的一部分，称为 Backend-Web-SRV。
• 计算机 Workstation-Client1 的用户将使用 Windows Active Directory 帐户登录到计算机。
• 然后，他们将启动浏览器（Microsoft Edge），导航到位于 Web-Server 上的网站，这是用于 Primary-IIS-SRV 的别名，并使用 Kerberos 通过集成的Windows 身份验证进行身份验证。
• 位于 Web-Server 上的网站将使用经过身份验证的用户凭据对 API-Server（后端 Web-SRV 的别名）进行 HTTP 调用，以代表用户使用 Kerberos 凭据委派来检索应用程序数据。

以下步骤将帮助你排查这种情况的问题：安装程序适用于 Internet Explorer，但当用户采用 Microsoft Edge 时，他们将无法再使用凭据委派功能。 若要使用 Kerberos 凭据委派，请先参阅 Internet Explorer 中的 Kerberos 故障疑难解答。

受约束或不受约束的委派

在上述方案中，这两种配置都允许用户在通过前端 Web-Server 进行连接时，将凭据从计算机 Workstation-Client1 上的用户会话委托给后端 API 服务器。

在不受约束的 Kerberos 委派配置中，应用程序池标识在 Web-Server 上运行，并在 Active Directory 中配置为受信任，以便委派到任何服务。 在 Web-Server 上运行的应用程序池帐户可以将服务器上托管的网站经过身份验证的用户的凭据委托给 Active Directory 中的任何其他服务。 例如，SMTP 服务器、文件服务器、数据库服务器、另一个 Web 服务器等。这称为不受约束的委派，因为应用程序池帐户具有将凭据委派给它所联系的任何服务的权限（不受约束）。

在受限委派配置中，用作应用程序池标识的 Active Directory 帐户只能将经过身份验证的用户的凭据委托给已授权委派的服务列表。 如果驻留在名为 Web-Server 的服务器上的 Web 应用程序还必须联系数据库并代表用户进行身份验证，则必须将此服务主体名称（SPN）添加到授权服务列表中。

根据最低特权原则，约束委派比不受约束的委派更安全。 应用程序被授予其正常运行所需的权限，而不受约束的委派允许应用程序代表用户联系其不应联系的资源。

如何知道在客户端上获取的 Kerberos 票证是发送到 Web 服务器还是使用约束委派？

使用 Windows 中存在的 klist 命令工具列出来自客户端计算机的 Kerberos 票证缓存（上图中的 Workstation-Client1 ）。 查找名为 HTTP/<Web-Server> 名称的票证。 注意： <Web 服务器> 的名称是希望通过 Kerberos 联系并进行身份验证的服务的 SPN。 票证还包含几个标志。 其中两个是感兴趣的： forwardable 和 ok_as_delegate。

• 第一个标志 forwardable指示 KDC（密钥分发中心）可以根据需要颁发具有新网络掩码的新票证。 这样，用户就可以登录到远程系统，让远程系统代表用户获取新的票证，以登录到另一个后端系统，就像用户已本地登录到远程系统一样。

• 第二个标志 ok_as_delegate 指示用户尝试进行身份验证的服务的服务帐户（在上图中，托管 Web 应用程序池的 IIS 应用程序池的应用程序池帐户）对于不受约束的委派是受信任的。

如果这些服务使用不受约束的委派，则客户端计算机上的票证包含 ok_as_delegate 和 forwardable 标志。 在大多数情况下，配置约束委派时，票证不包含 ok_as_delegate 标志，但包含 forwardable 标志。

为什么不受约束的委派在 Internet Explorer 中工作，而不是在 Microsoft Edge 中工作？

尝试使用基于 Kerberos 的身份验证向网站进行身份验证时，浏览器会调用 Windows API 来设置身份验证上下文。 有问题的 API 是 InitializeSecurityContext。 此 API 可能会收到一系列标志，以指示浏览器是否允许 delegatable 用户收到的票证。 票证被标记为 delegatable 因为用户尝试进行身份验证的服务有权以不受约束的方式委托凭据。 但是，这并不意味着尝试进行身份验证的应用程序（在本例中是浏览器）应使用此容量。

默认情况下，Internet Explorer 会将标志传递给该标志 InitializeSecurityContext，指示是否可以委托票证，则应为该标志。 Microsoft版本 87 及更高版本中的 Edge 不会仅因为票证被标记而ok_as_delegate将标志InitializeSecurityContext传递给该标志。 不建议在应用程序中使用不受约束的委派，因为它为应用程序提供比所需的权限更多。 应用程序可以将用户的标识委托给域上的任何其他服务，并作为用户进行身份验证，这对于大多数使用凭据委派的应用程序来说都没有必要。 应用程序应仅联系在设置约束委派时指定的列表中的服务。

默认情况下，Microsoft Edge 适用于受约束委派，其中 Web-Server 上运行的 IIS 网站仅有权联系 API-Server 上托管的后端 API 站点，如下面列出的 Active Directory 的应用程序池标识帐户配置中所示：

使 Edge-Chromium 能够在 Active Directory 中使用不受约束的委派

出于兼容性目的，如果必须通过 Kerberos 维护使用不受约束的委派的应用程序，请启用 Microsoft Edge 以允许票证委派。 本文的以下部分详细介绍了以下步骤：

1. 在 Active Directory 中安装组策略中央存储的管理模板（如果尚不存在）。
2. 安装 Microsoft Edge 管理模板。
3. 创建新的组策略对象。
4. 编辑组策略的配置，以便在对服务器进行身份验证时允许不受约束的委派。
5. （可选）检查 Microsoft Edge 是否使用正确的委派标志。

步骤 1：安装 Active Directory 的管理模板

1. 从 管理模板（.admx） 下载模板（适用于 Windows Server 2019）。

2. 下载安装程序并将内容提取到所选文件夹。 只需将其提取到包的默认指定位置，即 C：\Program Files （x86）\Microsoft组策略\Windows 10 2018 年 10 月更新 （1809） v2\PolicyDefinitions。

3. 解压缩包后，在域控制器上找到 Sysvol 文件夹。 文件夹的路径为 C：\Windows\SYSVOL\sysvol\。 Sysvol 文件夹中是一个文件夹，其名称与 Active Directory 名称相同（在此示例中为 Oddessy.local）。 在此处，导航到 “策略 ”文件夹。 如果不存在，请创建名为“策略定义”的文件夹，如下所示：

   

4. 将 PolicyDefinitions 文件夹（从安装程序提取到 PolicyDefinitions 文件夹）的内容复制到域控制器的 sysvol 文件夹中的域内创建的 PolicyDefinitions 文件夹。

   注意

   安装程序提取的文件还包含本地化内容。 若要节省空间，请仅传输所需语言的本地化文件。 例如，名为 fr-FR 的文件夹包含法语中的所有本地化内容。

5. 传输完成后，请验证模板是否在 Active Directory 中可用。 为此，请打开 Microsoft管理控制台的组策略管理 管理管理单元（按 Windows+R，然后键入 gpmc.msc 启动）。 在组策略管理中，找到组策略对象并对其进行编辑。

   

   如上面的屏幕截图所示，在 “计算机配置” 节点下，是“ 策略 ”节点和管理 模板 节点。

步骤 2：安装 Microsoft Edge 管理模板

虽然域控制器上可能具有 策略管理模板 ，但你仍必须安装 Microsoft Edge Policy 文件才能访问旨在通过此浏览器启用双跃点不受约束的委派的策略。 若要安装 Microsoft Edge Policy 文件，请执行以下步骤：

1. 转到适用于企业下载网站的 Microsoft Edge。

2. 从 频道/版本下拉列表中选择要下载的版本 。 建议使用最新的稳定版本。

3. 从生成下拉列表中选择所需的生成，最后从平台下拉列表中选择目标操作系统。 选择完成后，将显示另外两个按钮（一个按钮和一个链接）。

   

4. 单击“GET POLICY 文件”并接受许可协议以下载名为“MicrosoftEdgePolicyTemplates.cab”的文件。 此文件包含 Microsoft Edge 的策略定义文件。

5. 双击该文件以浏览内容（具有相同名称的 zip 存档）。

6. 将 zip 存档的内容提取到本地磁盘上的文件夹。 提取的内容将包含一个名为 Windows 的文件夹，在其中可以找到名为 Admx 的子文件夹。 这将包含管理模板及其本地化版本（应使用英语以外的语言）。

   

7. 将管理模板从上一个目录传输到的 Sysvol 目录下的同一文件夹中传输 .admx 文件（在上面的示例中：C：\Windows\SYSVOL\sysvol\odessy.local\Policies\PolicyDefinitions）。

8. 打开 Active Directory 组策略编辑器并选择一个现有的组策略对象进行编辑，以检查新传输Microsoft Edge 模板是否存在。 这些将位于树视图的“管理模板”文件夹下名为“Microsoft Edge”的文件夹中：

   

步骤 3：创建新的组策略对象

下面介绍如何使用 Active Directory 组策略管理器 MMC 管理单元创建新的组策略对象：

1. 按 Windows+R 键打开 域控制器上的“运行 ”菜单。
2. 键入 Gpmc.msc 以打开Microsoft管理控制台并加载 Active Directory 组策略管理器管理单元。
3. 在控制台的树视图中找到组策略对象节点，右键单击该节点以打开上下文菜单。
4. 选择“新建”菜单项，填写要创建的组策略的名称，然后单击“确定”。

步骤 4：编辑组策略的配置，以便在向服务器进行身份验证时允许不受约束的委派

最后一步是启用策略，该策略允许Microsoft Edge 浏览器在使用 Kerberos 向启用了 Windows 集成的网站执行身份验证时将 ok_as_delegate 标志 InitializeSecurityContext 传递给 API 调用。 如果不知道 Microsoft Edge 浏览器是否使用 Kerberos 进行身份验证（而不是 NTLM），请参阅 Internet Explorer 中的 Kerberos 故障疑难解答。

在 Active Directory 组策略编辑器中，选择组策略对象，该对象将应用于 Active Directory 内部的计算机，你打算允许最终用户通过 Kerberos 身份验证进行身份验证，并通过不受约束的委派将其凭据委托给后端服务。 将从 Microsoft Edge 启用不受约束委派的策略位于 Microsoft Edge 模板的 Http 身份验证文件夹下，如下所示：

使用此设置可以配置允许 Kerberos 票证委派的服务器列表。

将新编辑的组策略对象应用到域中的客户端计算机后，请转到 Windows 集成身份验证故障排除诊断页中的测试身份验证页，并从 GitHub 上的 ASP.net 示例存储库下载whoami.aspx页。 它将生成 委托的 ImpersonationLevel 设置，而不是 模拟 信号，指示现在允许委派凭据。

若要测试策略是否已在客户端工作站上正确应用，请打开新的Microsoft Edge 选项卡并键入 edge://policy。

策略 AuthNegotiateDelegateAllowlist 应设置为指示允许Microsoft Edge 执行 Kerberos 票证委派的服务器名称的值。 如果策略未显示在列表中，则它尚未部署或部署在错误的计算机上。

步骤 5 （可选）：检查 Microsoft Edge 是否使用正确的委派标志

下面是故障排除/可选检查步骤。

配置和部署策略后，必须执行以下步骤来验证 Microsoft Edge 是否将正确的委派标志传递给 IntializeSecurityContext。 这些步骤使用已内置于 Microsoft Edge 或作为联机服务提供的工具。

1. 使用 Microsoft Edge 中提供的日志记录功能记录浏览器在请求网站时执行的操作。 要启用日志记录：

   1. 打开新的Microsoft Edge 窗口并键入 edge://net-export/。

   2. 跟踪时使用“包括 Cookie 和凭据”选项。 如果没有此选项，将省略身份验证跟踪级别数据。

      

   3. 单击“开始日志记录到磁盘”按钮，并提供要在其中保存跟踪的文件名。

   4. 打开另一Microsoft Edge 选项卡，导航到要使用 Microsoft Edge 执行集成Windows 身份验证的网站。

   5. 尝试进行身份验证后，返回到启用跟踪的上一个选项卡，然后单击“ 停止日志记录 ”按钮。 跟踪接口将指示包含跟踪的文件已写入到的位置。

2. 使用包含跟踪的 JSON 文件查看浏览器在尝试进行身份验证时传递给 InitializeSecurityContext 函数的参数。 若要分析跟踪，请使用 netlog_viewer。

3. 分析跟踪内部是如下所示的事件日志：

   t=3076 [st=12]       +AUTH_LIBRARY_INIT_SEC_CTX  [dt=3]
                         --> flags = {"delegated":false,"mutual":false,"value":"0x00000000"}
                         --> spn = "HTTP/web-server.odessy.local"
   

   此日志显示：

   • AUTH_LIBRARY_INIT_SEC_CTX 表示浏览器正在调用函数 InitializeSecurityContext 。
   • "delegated":false 表示即使票证标记为 delegatable“票证”，也不应委托票证。
   • "mutual":false 表示客户端（浏览器）不需要服务器也向客户端进行身份验证并证明其身份。 只有客户端应向服务器进行身份验证以证明其标识。
   • HTTP/web-server.odessy.local 是浏览器在进行身份验证调用时使用的 SPN。

详细信息

Windows 集成身份验证故障排除的诊断页面