gMSA アカウントが自動的にローテーションされると、約 1 ～ 10 分間ログインに失敗することが見られます。これは、MS SQL サーバーに接続する gMSA クライアント アカウントで特に顕著ですが、他の gMSA アカウントでも発生すると思います。MS SQL サーバーは gMSA アカウントとして実行されていませんが、アプリケーションは gMSA を使用して SQL へのクライアント接続を行います。デフォルトでは、ManagedPasswordIntervalInDays は 30 日ごとなので、毎月同じ時期にこの状態になります。
ドメイン コントローラーのログを確認すると、gMSA ユーザーのログイン失敗は表示されませんが、SQL サーバーは次のエラーをログに記録します。
統合セキュリティによる接続を確立中に、エラー コード 0x8009030c、状態 14 で SSPI ハンドシェイクが失敗しました。接続は閉じられました。理由: AcceptSecurityContext が失敗しました。オペレーティング システムのエラー コードに失敗の原因が示されています。ログオン試行が失敗しました [クライアント: xxxx]
私が調べたところ、このエラーは通常、ユーザー名とパスワードの組み合わせが間違っていることを示しています。
これは複数のクライアントで発生し、各クライアントは最終的に 1 ～ 10 分後に再度接続を開始します。すべてのクライアントが同時に接続を開始するわけではありませんが、その時間枠内でランダムに接続を開始するようです。
最初は、変更されたパスワードの AD レプリケーションに関連している可能性があると考え、すぐにレプリケートするように、既定のサイト間レプリケーション間隔を USE_NOTIFY に変更しました。レプリケーションが問題である場合、DC でログイン失敗が表示されるはずですが、DC でログオン失敗は表示されません。SQL サーバーが認証トークンをキャッシュしている可能性もあると考えましたが、その場合、すべてのクライアントが同時に解決されるはずです (つまり、SQL サーバーが更新されたとき)。クライアントがそれぞれ異なる時間に再び動作を開始するため、SQL サーバー側ではなく、クライアント側に問題があるように見えます。gMSA パスワードのキャッシュか、タイムアウトと再試行バックオフに関連する何かかもしれません。
答え1
SPN の問題により、gMSA が Kerberos ではなく NTLM 経由で SQL Server に認証するようになったため、同じエラーが発生していました。SQL Server にログインしてセッションを確認すると、sys.dm_exec_connectionsNTLM を使用したセッションのリストが表示されます。
klist sessions( CLI からセッションを表示することもできます)
ログ分析ツールでエラーとパスワードの変更を関連付けることができたので、それが原因だとわかりました。SCM がパスワードのコピーをどのくらいの頻度で更新するかはわかりませんが、サービスが SQL Server に認証して Kerberos を使用している場合、パスワードの変更は Kerberos セッションの有効期間/更新とは無関係であるはずなので、生成されたエラーはパスワードが NTLM 経由で SQL Server ホストに送信されていることを示す確かな手掛かりです。SPN の問題 (追加の DNS A レコードが原因) を修正すると、セッションは Kerberos 認証に切り替わりました。
答え2
これは、Windows サービスの構成方法によるものであることがわかりました。Windows サービスは、管理対象アカウントを使用する Windows サービスではなく、たまたま gMSA アカウントであった通常のユーザー アカウントを使用する標準サービスとして構成されていました。
これは次の方法で確認できます:
>sc.exe qmanagedaccount ServiceName
[SC] QueryServiceConfig2 SUCCESS
ACCOUNT MANAGED : FALSE
これは実行することで変更できます
sc.exe managedaccount ServiceName TRUE
管理対象の Windows サービス アカウントの種類を変更した後、初期テストでは、gMSA パスワードのローテーション中にログインが成功するようになったことが示されています。