包含服务主体名称 (SPN) 的 Kerberos
适用于：Azure Stack HCI 版本 23H2 和 22H2;Windows Server 2022、Windows Server 2019
本文介绍如何将 Kerberos 身份验证与服务主体名称 (SPN) 配合使用。
对于与管理客户端的通信，网络控制器支持多种身份验证方法。 可以使用基于 Kerberos 的身份验证、基于 X509 证书的身份验证。 还可以选择不对测试部署使用身份验证。
System Center Virtual Machine Manager 使用基于 Kerberos 的身份验证。 如果使用基于 Kerberos 的身份验证，则必须在 Active Directory 中为网络控制器配置 SPN。 SPN 是网络控制器服务实例的唯一标识符，Kerberos 身份验证使用该标识符将服务实例与服务登录帐户相关联。 有关详细信息，请参阅服务主体名称。
配置服务主体名称 (SPN)
网络控制器会自动配置 SPN。 只需为网络控制器计算机提供注册和修改 SPN 的权限即可。
在域控制器计算机上，打开“Active Directory 用户和计算机”。
选择“查看”>“高级”。
在“计算机”下，找到其中一个网络控制器计算机帐户，然后右键单击并选择“属性”。
选择“安全” 选项卡，单击“高级” 。
在列表中，如果未列出所有网络控制器计算机帐户或具有所有网络控制器计算机帐户的安全组，请单击“ 添加 ”将其添加。
对于每个网络控制器计算机帐户或包含网络控制器计算机帐户的单个安全组：
选择帐户或组，然后单击“编辑”。
在“权限”下，选择“验证写入 servicePrincipalName”。
向下滚动，然后在“属性”下选择以下选项：
读取 servicePrincipalName
写入 servicePrincipalName
单击“确定”两次。
为每个网络控制器计算机重复步骤 3 - 6。
关闭“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 的权限。