密码轮换期间 gMSA 帐户身份验证失败

Question

当我们的 gMSA 帐户自动轮换时，我们会看到大约 1-10 分钟的登录失败。这对于连接到 MS SQL 服务器的 gMSA 客户端帐户尤为明显，但我认为其他 gMSA 帐户也会发生这种情况。MS SQL 服务器不是作为 gMSA 帐户运行的，但我们的应用程序使用 gMSA 来建立到 SQL 的客户端连接。默认情况下 ManagedPasswordIntervalInDays 是每 30 天一次，所以我们每个月都会在同一时间看到这个。

当我检查域控制器日志时，我没有看到 gMSA 用户的任何登录失败，但是 SQL 服务器记录了以下错误

SSPI 握手失败，错误代码为 0x8009030c，在建立具有集成安全性的连接时状态 14；连接已关闭。原因：AcceptSecurityContext 失败。操作系统错误代码指示失败的原因。登录尝试失败 [CLIENT: xxxx]

根据我的发现，此错误通常表示用户名/密码组合错误。

这发生在多个客户端上，每个客户端最终都会在 1-10 分钟后重新开始连接。客户端不会同时开始连接，但在那个时间窗口内似乎是随机的。

一开始我觉得可能跟修改密码的AD复制有关，所以我们把默认的跨站复制间隔修改为USE_NOTIFY来立即复制。如果复制是问题所在，我希望在 DC 上看到登录失败，而在 DC 上看不到登录失败。我还以为 SQL 服务器可能正在缓存身份验证令牌，但如果是这种情况，我希望看到所有客户端同时解析（即当 SQL 服务器刷新时）因为客户端每个都开始重新工作在不同的时间，它似乎不在 SQL 服务器端，而更可能在客户端。也许缓存 gMSA 密码，或者可能与超时和重试回退相关的东西。

Answer 1

我发现这是由于Windows服务的配置方式造成的。Windows 服务被配置为使用常规用户帐户的标准服务，该帐户恰好是 gMSA 帐户，而不是使用托管帐户的 Windows 服务。

这可以通过以下方式验证：

>sc.exe qmanagedaccount ServiceName

[SC] QueryServiceConfig2 SUCCESS

ACCOUNT MANAGED : FALSE

这可以通过运行来更改

sc.exe managedaccount ServiceName TRUE

更改要管理的 Windows 服务帐户类型后，初始测试显示在 gMSA 密码轮换期间登录现已成功。

Answer 2

由于 SPN 问题导致 gMSA 通过 NTLM 而不是 Kerberos 向 sql server 进行身份验证，我们生成了相同的错误。如果您登录 sql server 并通过检查会话，sys.dm_exec_connections您应该会看到 NTLM 的会话列表

（您也可以使用klist sessionscli 查看会话）

我们能够使用日志分析工具将错误与密码更改关联起来，因此我们知道这是罪魁祸首。我不知道 SCM 刷新其密码副本的频率，但如果服务正在向 sql server 进行身份验证并使用 Kerberos，我相信密码更改应该独立于 Kerberos 会话生命周期/更新，因此生成的错误是一个可靠的线索密码通过 NTLM 发送到 sql server 主机。一旦我们解决了 SPN 问题（这是由于额外的 DNS A 记录），会话就会切换到 Kerberos 身份验证。