當我們的 gMSA 帳戶自動輪調時，我們會看到登入失敗約 1-10 分鐘。這對於連接到 MS SQL 伺服器的 gMSA 用戶端帳戶尤其明顯，但我認為其他 gMSA 帳戶也會發生這種情況。 MS SQL 伺服器並非以 gMSA 帳戶執行，但我們的應用程式使用 gMSA 建立與 SQL 的用戶端連線。預設情況下，ManagedPasswordIntervalInDays 是每 30 天一次，因此我們每個月都會在同一時間看到這一點。
當我檢查網域控制站日誌時，我沒有看到 gMSA 使用者的任何登入失敗，但 SQL Server 記錄了以下錯誤
在建立具有整合安全性的連線時，SSPI 握手失敗，錯誤代碼為 0x8009030c，狀態 14；連線已關閉。原因：AcceptSecurityContext 失敗。作業系統錯誤代碼指示故障原因。登入嘗試失敗 [客戶端：xxxx]
據我所知，此錯誤通常表示使用者名稱/密碼組合錯誤。
這種情況發生在多個客戶端上，每個客戶端最終都會在 1-10 分鐘後重新開始連線。客戶端並非同時開始連接，但在該時間窗口內似乎是隨機的。
最初我認為可能與更改密碼的AD複製有關，因此我們將預設的站間複製間隔修改為USE_NOTIFY以立即複製。如果複製是問題所在，我希望在 DC 上看到登入失敗，但在 DC 上我沒有看到登入失敗。我還以為 SQL 伺服器可能正在快取身份驗證令牌，但如果是這種情況，我希望看到所有客戶端同時解析（即當 SQL 伺服器刷新時），因為客戶端每個都重新開始工作在不同的時間，它似乎不是在SQL 伺服器端，更可能是在客戶端。也許快取 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 密碼輪調期間登入現已成功。