当我们的 gMSA 帐户自动轮换时，我们会看到登录失败大约 1-10 分钟。这对于连接到 MS SQL 服务器的 gMSA 客户端帐户尤其明显，但我认为其他 gMSA 帐户也会发生这种情况。MS SQL 服务器未作为 gMSA 帐户运行，但我们的应用程序使用 gMSA 与 SQL 建立客户端连接。默认情况下，ManagedPasswordIntervalInDays 为每 30 天一次，因此我们每个月都会在同一时间看到这种情况。
当我检查域控制器日志时，我没有看到 gMSA 用户的任何登录失败，但 SQL 服务器记录了以下错误
建立集成安全性连接时，SSPI 握手失败，错误代码为 0x8009030c，状态为 14；连接已关闭。原因：AcceptSecurityContext 失败。操作系统错误代码指示失败的原因。登录尝试失败 [客户端：xxxx]
据我发现，此错误通常表示用户名/密码组合错误。
这种情况发生在多个客户端上，每个客户端最终都会在 1-10 分钟后再次开始连接。客户端不会同时开始连接，但似乎是在该时间窗口内随机发生的。
最初，我认为这可能与更改密码的 AD 复制有关，因此我们将默认站点间复制间隔修改为 USE_NOTIFY 以立即复制。如果复制是问题所在，我预计会看到 DC 上的登录失败，但我没有看到 DC 上的登录失败。我还以为 SQL Server 可能正在缓存身份验证令牌，但如果是这种情况，我希望看到所有客户端同时解析（即当 SQL Server 刷新时）由于每个客户端都在不同的时间重新开始工作，因此它似乎不在 SQL Server 端，而更可能是客户端端的问题。可能是缓存了 gMSA 密码，也可能是与超时和重试退避有关的东西。
答案1
由于 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 身份验证。
答案2
我发现这是由于 Windows 服务的配置方式造成的。Windows 服务使用常规用户帐户（恰好是 gMSA 帐户）配置为标准服务，而不是使用托管帐户的 Windows 服务。
可以通过以下方法验证：
>sc.exe qmanagedaccount ServiceName
[SC] QueryServiceConfig2 SUCCESS
ACCOUNT MANAGED : FALSE
可以通过运行来更改
sc.exe managedaccount ServiceName TRUE
更改要管理的 Windows 服务帐户类型后，初步测试表明，在 gMSA 密码轮换期间登录现在可以成功。