摘要
2022 年 1 月 11 日更新和更高版本中Windows CVE-2022-21920 Windows保护。 这些更新包含改进的逻辑，用于检测使用 Microsoft Negotiate 身份验证协议时由 3 部分服务主体 名称 所受到的降级攻击。
本文提供有关 Kerberos 身份验证不成功的指南。
详细信息
安装 2022 年 1 月 11 日 Windows 更新和更高版本 Windows 更新可能会导致在 Kerberos 身份验证不成功的 3 部分 SNS 中身份验证失败。 对于这些环境，3 部分 SNS 的 Kerberos 身份验证可能一段时间未运行。 你可能会在客户端系统上看到Windows事件，以帮助进行会审。
|
LSA 事件 40970 屏幕截图，用于标识 Microsoft 测试环境中特定 SPN 的 NTLM 回退。 |
LSA 事件 40970 文本版本 |
|
|
联系 3 部分 SPN 时，安全系统检测到降级尝试 <SPN 名称> 错误代码为"Windows Server 上的 SAM 数据库没有用于工作站信任关系的计算机帐户" (0x0000018b) 身份验证。 |
操作
Microsoft 建议对 3 部分 SPN 的 Kerberos 身份验证失败的原因进行会审。 Kerberos 身份验证失败的一些常见原因包括：
-
用作身份验证目标的 SPN 格式不正确。 有关详细信息，请参阅唯一 SNS 的名称格式。
注意: 应用程序和 API 对于构成其服务合法 SPN 的定义可能更严格或不同。
合法 SPN 的示例
http/webserver
Host/machine2.contoso.com
Ldap/machine1.contoso.com/contoso.com
Service/machine1：10100
可能格式错误的 SNS 的示例SPN
原因
主机/主机/计算机1
主机/主机很可能是错误，因为"主机"通常是服务类，而不是计算机名称。 合法 SPN 可能是主机/计算机 1。
Ldap/machine/contoso.com：10100
可以在主机名上指定端口 ("machine") 服务实例名称上指定端口。 合法 SPN 可能是"ldap/machine：10100/contoso.com"
Ldap/dc-a/DC=CONTOSO，DC=COM
某些 API 需要 DNS 名称而不是 FQDN。 例如 ，DsBindA 函数 (ntdsapi.h) DNS 名称中传递。 如果传递了 FQDN，则可能会导致 SPN 格式错误。
合法的 SPN 可能是"ldap/dc-a/contoso.com"若要解决这些问题，请考虑使用正确的 SPN 或将格式不正确的 SPN 注册到正确的服务帐户。
-
用作身份验证目标的 SPN 不存在。 若要解决此问题，请考虑将 SPN 注册到正确的服务帐户。
-
Windows客户端计算机没有域控制器的视线 (例如，域控制器处于脱机状态、无法在 DNS 中发现，或者对 KDC 端口的访问被阻止) 。
-
在 NetBIOS 名称不起作用的情况下，可能正在使用 NetBIOS 名称。 例如，从未加入域计算机访问域资源，NetBIOS 名称解析被禁用或无法工作。
Microsoft 建议使用用户主体名称 ( UPN) 域名系统 (DNS) 名称而不是 NetBIOS 名称。
注册 SNS
根据应用程序和环境的配置，可以在服务帐户的服务主体名称属性或 Kerberos 客户端 尝试建立 Kerberos 连接的 Active Directory 域中的计算机帐户中配置 SNS。 若要使 Kerberos 身份验证正常工作，目标 SPN 必须有效。
有关如何启用 Kerberos 身份验证的指导，请参阅每个特定应用程序的部署文档或支持提供程序。 某些应用程序安装程序或应用程序会自动注册 SNS。 开发人员和管理员有不同的选项来注册 SPN：
-
若要手动注册服务实例的 SPN，请参阅 Setspn。
-
若要以编程方式注册服务实例的 SNS，请参阅服务如何注册 其 SNS， 描述如何：
-
调用DsGetSpn函数，为服务实例创建一个或多个唯一的 SPN。 有关详细信息，请参阅唯一 SNS 的名称格式。
-
调用DsWriteAccountSpn函数以在服务的登录帐户上注册名称。
-
已知问题
目前，此更新没有已知问题。
