包含服务主体名称 (SPN) 的 Kerberos

适用于：Azure Stack HCI 版本 22H2 和 21H2；Windows Server 2022、Windows Server 2019

对于与管理客户端的通信，网络控制器支持多种身份验证方法。 可以使用基于 Kerberos 的身份验证、基于 X509 证书的身份验证。 还可以选择不对测试部署使用身份验证。

System Center Virtual Machine Manager 使用基于 Kerberos 的身份验证。 如果使用基于 Kerberos 的身份验证，则必须为 Active Directory 中的网络控制器配置服务主体名称 (SPN)。 SPN 是网络控制器服务实例的唯一标识符，Kerberos 身份验证使用该标识符将服务实例与服务登录帐户相关联。 有关详细信息，请参阅服务主体名称。

配置服务主体名称 (SPN)

网络控制器会自动配置 SPN。 只需为网络控制器计算机提供注册和修改 SPN 的权限即可。

1. 在域控制器计算机上，打开“Active Directory 用户和计算机”。

2. 选择“查看”>“高级”。

3. 在“计算机”下，找到其中一个网络控制器计算机帐户，然后右键单击并选择“属性”。

4. 选择“安全” 选项卡，单击“高级” 。

5. 在列表中，如果未列出所有网络控制器计算机帐户或包含所有网络控制器计算机帐户的安全组，请单击“添加”以添加它。

6. 对于每个网络控制器计算机帐户或包含网络控制器计算机帐户的单个安全组：

   a. 选择帐户或组，然后单击“编辑”。

   b. 在“权限”下，选择“验证写入 servicePrincipalName”。

   d. 向下滚动，然后在“属性”下选择以下选项：

   • 读取 servicePrincipalName

   • 写入 servicePrincipalName

   e. 单击“确定”两次。

7. 为每个网络控制器计算机重复步骤 3 - 6。

8. 关闭“Active Directory 用户和计算机”。

未能提供 SPN 注册/修改的权限

在新的 Windows Server 2019 部署中，如果选择使用 Kerberos 进行 REST 客户端身份验证，并且不向网络控制器节点授予注册或修改 SPN 的权限，则网络控制器上的 REST 操作会失败，从而阻碍对 SDN 的管理。

如果要从 Windows Server 2016 升级到 Windows Server 2019，并已选择使用 Kerberos 进行 REST 客户端身份验证，REST 操作不会受阻，从而确保了现有生产部署的透明度。

如果未注册 SPN，REST 客户端身份验证将使用不太安全的 NTLM。 还会在 NetworkController-Framework 事件通道的管理员通道中收到关键事件，要求你向网络控制器节点提供注册 SPN 的权限。 提供权限后，网络控制器会自动注册 SPN，且所有客户端操作都会使用 Kerberos。

提示

通常，可以将网络控制器配置为对基于 REST 的操作使用 IP 地址或 DNS 名称。 但是，配置 Kerberos 时，不能将 IP 地址用于对网络控制器的 REST 查询。 例如，可以使用 <https://networkcontroller.consotso.com>，但不能使用 <https://192.34.21.3>。 如果使用 IP 地址，服务主体名称无法正常发挥作用。

如果在 Windows Server 2016 中将 IP 地址用于 REST 操作并使用 Kerberos 身份验证，则实际通信中会使用 NTLM 身份验证。 在此类部署中，升级到 Windows Server 2019 后，将继续使用基于 NTLM 的身份验证。 若要迁移到基于 Kerberos 的身份验证，必须在 REST 操作中使用网络控制器 DNS 名称，并为网络控制器节点提供注册 SPN 的权限。

---