gMSA を使用して SQL Server の Kerberos と認証の失敗をトラブルシューティングする

適用対象: WindowsのSQL Server

まとめ

この記事は、SQL Server がグループ管理サービス アカウント (gMSA) で実行されている場合に発生する、Kerberos、リンク サーバー、および可用性グループの認証の失敗のトラブルシューティングに役立ちます。 これらのエラーの原因は、サービス アカウントが gMSA かドメイン ユーザー アカウントかです。 完全な診断パスの場合は、次の参照を使用します。

サービス プリンシパル名 (SPN) の所有権、委任、エンドポイントのアクセス許可など、gMSA にのみ適用される違いについては、次のセクションを使用します。

開始する前に、前提条件を確認し、「gMSA を使用したSQL Serverセットアップ、起動、認証エラーのトラブルシューティング」のクイック検証チェックリストを実行します。

Kerberos または SPN エラー

gMSA の SPN を確認する

  • コンピューター アカウント形式の名前を持つ SPN を一覧表示します。 gMSA はコンピューター クラスのオブジェクトであるため、アカウント名には末尾にドル記号が必要です。

    setspn -L CONTOSO\SQLgMSA$
setspn -Q MSSQLSvc/sql01.contoso.com:1433

  • SPN の自動登録が成功できることを確認します。 SQL Serverは、サービス アカウントが独自のservicePrincipalName属性に書き込むことができる場合にのみ、起動時にその SPN を登録します。 gMSA にそのアクセス許可がない場合、SQL Server エラー ログは SPN を登録できなかったことを報告し、管理者はそれを手動で登録する必要があります。 詳細については、「 Kerberos 接続のサービス プリンシパル名を登録する」を参照してください。

  • サービス アカウントの変更後に SPN 所有権を再確認します。 前のアカウントに登録された SPN は、そのアカウントに残ります。 それらを移動または削除して、想定される MSSQLSvc SPN の所有者が、現在 SQL Server を実行している gMSA のみになるようにします。

gMSA の Kerberos 認証を確認する

  1. 再テストする前に、クライアントで次のコマンドを実行します。

    klist purge

  2. リモート Windows認証セッションから再接続し、次のクエリを実行します。

    SELECT c.auth_scheme, c.net_transport, c.client_net_address
FROM sys.dm_exec_connections AS c
WHERE c.session_id = @@SPID;

    予期される結果: 新しいリモート Windows認証接続レポートKERBEROS。

不足している、重複している、または正しく配置されていない SPN と Kerberos Configuration Managerについては、次のリファレンスを参照してください。

リンク サーバーまたはダブルホップの失敗

現在のセキュリティ コンテキストを使用するリンク サーバーは、2 番目のホップがユーザー ID を委任できない場合、 NT AUTHORITY\ANONYMOUS LOGON で失敗します。 適切な SPN が必要ですが、2 番目のホップ自体は有効になりません。

gMSA の委任設定を確認する

  • msDS-AllowedToDelegateToを設定するか、またはターゲットでリソース ベースの制約付き委任を構成して、gMSA オブジェクトに対して制約付き委任を構成します。 ユーザー アカウントで構成された委任は適用されません。
  • サービス アカウントをドメイン ユーザー アカウントから gMSA に変更した場合は、委任設定が gMSA で再作成されたことを確認します。 委任は SPN で転送されません。

委任を調査する前に、最初のホップを確認してください。

SELECT ORIGINAL_LOGIN() AS original_login, SUSER_SNAME() AS execution_login, c.auth_scheme
FROM sys.dm_exec_connections AS c
WHERE c.session_id = @@SPID;

期待される結果: 最初のホップは KERBEROS と表示されます。

完全なダブルホップ診断パスについては、次のリファレンスを参照してください。

可用性グループ レプリカの認証エラー

可用性グループの接続は、エンドポイントの状態、URL とポート、ファイアウォール、DNS、 CONNECT アクセス許可、サービス アカウント認証によって異なります。 これらはクライアント Kerberos とは別に検証し、エラーが Kerberos または SSPI を具体的に示す場合にのみ SPN 証拠を使用します。

gMSA のエンドポイントのアクセス許可を確認する

  • データベース ミラーリング エンドポイントの CONNECT を、すべてのレプリカの [CONTOSO\SQLgMSA$] フォームの gMSA ログインに付与します。 前のサービス アカウント用に作成されたログインでは、gMSA は承認されません。
  • レプリカが異なる gMSA で実行されている場合は、各レプリカに、すべてのパートナー サービス アカウントのログインと CONNECT アクセス許可があることを確認します。
SELECT ar.replica_server_name, ars.role_desc, ars.connected_state_desc, ars.synchronization_health_desc
FROM sys.availability_replicas AS ar
LEFT JOIN sys.dm_hadr_availability_replica_states AS ars ON ar.replica_id = ars.replica_id;

SELECT name, state_desc, type_desc, port
FROM sys.tcp_endpoints
WHERE type_desc = 'DATABASE_MIRRORING';

予想される結果: エンドポイントが STARTEDされ、ポートに到達でき、レプリカの状態が CONNECTEDに進行します。

サービス アカウントに固有ではないエンドポイント、ファイアウォール、接続のトラブルシューティングについては、「 可用性レプリカが Always On 可用性グループ内で切断されている 」および「 Always On 可用性グループの構成のトラブルシューティング」を参照してください。

診断データの収集

これらの手順を完了しても認証が失敗する場合は、SQL Server ホストと影響を受けるすべてのレプリカから、同じ障害間隔で診断データを収集します。 収集する gMSA 固有の証拠と標準的なSQL Server ログについては、gMSA トラブルシューティングの概要の診断データの収集に関するページを参照してください。 そのデータを使用して調査を続行するか、サポート ケースを開きます。

関連するコンテンツ

  • 最終更新: