Windows 認証を使用してSQL サーバーに接続するときに "SSPI コンテキストを生成できません" エラー
適用対象: SQL Server
元の KB 番号: 811889
注:
トラブルシューティングを開始する前に、 前提条件 を確認し、チェックリストを確認することをお勧めします。
Windows 認証を使用してSQL Server インスタンスをリモートで接続すると、次のエラー メッセージが表示されます。
対象のプリンシパル名が間違っています。 SSPI コンテキストを生成できません。
よく寄せられる質問
SSPI とは
セキュリティ サポート プロバイダー インターフェイス (SSPI) は、TCP/IP ソケットなど、任意の汎用データ トランスポート層に対する委任と相互認証を許可する一連の Windows API です。 1 つ以上のソフトウェア モジュールは、実際の認証機能を提供します。 各モジュールはセキュリティ サポート プロバイダー (SSP) と呼ばれ、ダイナミック リンク ライブラリ (DLL) として実装されます。
Kerberos とは
Kerberos v5 プロトコルは業界標準のセキュリティ パッケージであり、Windows オペレーティング システムの 3 つのセキュリティ パッケージの 1 つです。 詳細については、セキュリティ サポート プロバイダー (SSP) を参照してください。
"SSPI コンテキストを生成できません" エラーは何を意味しますか?
このエラーは、SSPI が TCP/IP または名前付きパイプを介してクライアント資格情報をSQL Serverに委任するために Kerberos 認証を試行したが使用できないことを意味します。 ほとんどの場合、サービス プリンシパル名 (SPN) が正しく構成されていないと、このエラーが発生します。
SPN とは
サービス プリンシパル名 (SPN) は、サービス インスタンスの一意の識別子です。 SPN は、サービス インスタンスをサービス ログオン アカウントに関連付けるために Kerberos 認証 によって使用されます。 この関連付けプロセスを使用すると、クライアント アプリケーションは、クライアントにアカウント名がない場合でも、アカウントを認証するようにサービスに要求できます。
たとえば、SQL Serverのインスタンスを実行しているサーバーの一般的な SPN は次のとおりです。
MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433
既定のインスタンスの SPN の形式は、名前付きインスタンスの SPN と同じです。 ポート番号は、SPN を特定のインスタンスに結び付けるものです。 SQL サーバーサービス SPN の登録の詳細については、Kerberos 接続のサービス プリンシパル名を登録するを参照してください。
SSPI で NTLM 認証または Kerberos 認証が使用されるのはなぜですか?
Windows 認証は、ユーザーがSQL サーバーに対して認証するために推奨される方法です。 Windows 認証を使用するクライアントは、NTLM または Kerberos を使用して認証されます。
SQL Server クライアントが、SQL Serverを実行しているリモート サーバーに接続する TCP/IP ソケットに対して統合セキュリティを使用する場合、SQL Server クライアント ネットワーク ライブラリは SSPI API を使用してセキュリティ委任を実行します。 SQL Server ネットワーク クライアントは AcquireCredentialsHandle 関数を呼び出し、パラメーターの "negotiate" pszPackage を渡します。 このプロセスは、基になるセキュリティ プロバイダーに委任をネゴシエートするように通知します。 このコンテキストでは、"ネゴシエート" とは、Windows ベースのコンピューターで Kerberos または NTLM 認証を試してみることを意味します。 つまり、SQL Serverを実行している移行先コンピューターに SPN が関連付けられて正しく構成されている場合、Windows は Kerberos 委任を使用します。 それ以外の場合、Windows は NTLM 委任を使用します。 SQL Server クライアントが、SQL Serverが存在する同じコンピューターでローカルに接続している場合は、常に NTLM が使用されます。
Kerberos で問題が発生した後、接続が NTLM にフェールオーバーされないのはなぜですか?
クライアント上のSQL Server ドライバー コードは、ドライバーがWindows 認証によりSQL Serverに接続するときに、WinSock ネットワーク API を使用して、サーバーの完全修飾 DNS を解決します。 この操作を実行するために、ドライバー コードは gethostbyaddr と gethostbyname WinSock API を呼び出します。 統合セキュリティが使用されている場合、IP アドレスまたはホスト名がサーバーの名前として渡された場合でも、ドライバーはサーバーの完全修飾 DNS を解決しようとします。
クライアント上のSQL サーバードライバーがサーバーの完全修飾 DNS を解決すると、対応する DNS を使用してサーバーの SPN が形成されます。 そのため、WinSock によって IP アドレスまたはホスト名を完全修飾 DNS にする際に問題が発生すると、SQL Server ドライバーによってサーバーの無効な SPN が作成される可能性があります。
たとえば、次のように無効な SPN を解決するために、クライアント側のSQL Server ドライバーを完全修飾 DNS として使用できます。
MSSQLSvc/SQLSERVER1:1433MSSQLSvc/123.123.123.123:1433MSSQLSvc/SQLSERVER1.antartica.corp.mycompany.com:1433MSSQLSvc/SQLSERVER1.dns.northamerica.corp.mycompany.com:1433
SQL Server ドライバーが無効な SPN を形成した場合でも、SSPI インターフェイスが Active Directory サービスで SPN の検索を試行するため、認証は機能します。 SSPI インターフェイスで SPN が見つからない場合、Kerberos 認証は実行されません。 その時点で、SSPI レイヤーは NTLM 認証モードに切り替わり、ログオンでは NTLM 認証が使用され、通常は成功します。 SQL Server ドライバーが、適切なコンテナーに割り当てられていない有効な SPN を形成する場合、ドライバーは SPN を試行しますが、使用できません。 この場合、"SSPI コンテキストを生成できません" というエラーが発生する可能性があります。 SQL Server スタートアップ アカウントがローカル システム アカウントの場合、適切なコンテナーはコンピューター名です。 その他のアカウントの場合、適切なコンテナーは SQL Server のスタートアップ アカウントです。 認証では最初に検出された SPN が使用されるため、不適切なコンテナーに割り当てられた SPN がないことを確認します。 つまり、各 SPN は 1 つのコンテナーにのみ割り当てる必要があります。
接続の認証方法を確認するにはどうすればよいですか?
接続の認証方法を確認するには、次のクエリを実行します。
SELECT net_transport, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;
詳細については、「 認証の種類が Kerberos かどうかを判断する方法」を参照してください。
SQL Server の SPN を作成する方法は?
SQL Server データベース エンジンのインスタンスが起動すると、SQL Server は DsWriteAccountSpn API を呼び出して、SQL Server サービスの SPN を自動的に登録しようとします。 この呼び出しが成功するのは、SQL Server サービス アカウントに Active Directory の servicePrincipalName 読み取り権限と servicePrincipalName 書き込み権限がある場合です。 それ以外の場合は、Active Directory 管理者が Microsoft Kerberos Manager for SQL Server または組み込みの Setspn ツールを使用して、正しい SPN を手動で登録する必要があります。 SQL Server に対する SPN の管理の詳細については、「Kerberos 接続のサービス プリンシパル名を登録する」を参照してください。
Kerberos Configuration Manager でエラーを修正する (推奨)
注:
この手順は、これらのエラー メッセージが、断続的にではなく、常に表示される状況にのみ適用されます。
Kerberos 接続が失敗する理由には、SPN の設定ミス、名前解決の問題、SQL Server サービスのスタートアップ アカウントの権限不足など、さまざまな理由があります。 Microsoft Kerberos Configuration Manager (KCM) は、エラーの原因を確認するのに役立つツールです。 KCM には、処理中に特定した問題を修正するためのオプションも用意されています。
以下の手順に従い、KCM を使用してエラーを解決します。
接続の問題があるコンピューターで、Kerberos Configuration Manager をダウンロードしてインストールします。
%SystemDrive%:\Program Files\Microsoft\Kerberos Configuration Manager フォルダーから KerberosConfigMgr.exe を開始します。 次に、接続できない SQL Server コンピューターに対して接続できるアクセス権限を持つドメイン アカウントを使用します。
[接続] を選択し、SQL Server コンピューターで KCM を実行している場合は、シナリオによるためサーバー名とその他の詳細を空白のままにします。 [接続] を選択して分析を実行します。 KCM が必要な情報の取得を完了すると、自動的に [SPN] タブに切り替わり、既定では SQL Server、SQL Server Reporting Services、Analysis Services、AG リスナーの情報が表示されます。 このエラーのトラブルシューティングを行うには、SQL Server 以外の選択をオフにします。
[状態] 欄でツールの診断結果を確認し、関連する手順に従って問題を解決します。
状態 詳細情報 アクション Good チェックされた項目は正しく構成されています。 出力結果の次の項目に進むことができます。 操作は必要ありません 必要な SPN がありません この状態が報告されるのは、[必須 SPN] 列で特定された SPN が、Active Directory の SQL Server スタートアップ アカウントで見つからない場合です。 1. [修正] を選択して、[警告] ダイアログ ボックスの情報を確認します。
2. [はい] を選択して、不足している SPN を Active Directory に追加します。
3. ドメイン アカウントに Active Directory を更新するために必要なアクセス許可がある場合、必要な SPN が Active Directory に追加されます。
4. ドメイン アカウントに Active Directory を更新するために必要なアクセス許可がない場合は、 Generate or Generate All を使用して、Active Directory 管理者が不足している SPN を追加するのに役立つスクリプトを生成します。
5. SPN が追加されたら、Kerberos Configuration Manager をもう一度実行して、SPN の問題が解決されたことを確認します。
6. さらに、次のコマンドを使用できます。
- を使用してSETSPN -Q spnName、SPN とその現在のアカウントを見つけます。
- 正しくないアカウントから SPN を削除するには、 を使用SETSPN -Dします。Kerberos 構成を使用するには TCP を有効にする必要があります これが発生するのは、クライアント コンピューターで TCP が有効になっていない場合です。 SQL Server インスタンスの TCP/IP プロトコルを有効にするには、次の手順に従います。
1. SQL Server 構成マネージャーの [コンソール] ウィンドウで、[SQL Server ネットワーク構成] を展開します。
2. コンソール ウィンドウで、インスタンス名 として<[プロトコル] を選択します>。
3. [詳細] ウィンドウで [TCP/IP] を右クリックし、[削除] を選択します。
4. [コンソール] ウィンドウで、[SQL Server サービス] を選択します。
5. 詳細 ウィンドウで、SQL Server (<インスタンス名>) を右クリックし、[ 再起動 ] を選択して SQL Server サービスを停止して再起動します。
詳細については、「サーバー ネットワーク プロトコルを有効または無効にする」を参照してください。動的ポート このメッセージは、動的ポート (既定の構成) を使用する名前付きインスタンスで表示されます。 Kerberos を使用して SQL Server に接続する必要がある環境では、名前付きインスタンスを静的ポートに設定し、そのポートを SPN 登録時に使用する必要があります。 静的ポートを使用するように SQL Server インスタンスを構成するには、次の手順に従います。
1. SQL Server 構成マネージャーのコンソール ウィンドウで[SQL Server ネットワーク構成]、[インスタンス名>の<プロトコル] の順に展開し、[TCP/IP] をダブルクリックします。
2. [TCP/IP プロパティ] ダイアログ ボックスで、[プロトコル] タブの [すべてリッスン] 設定を確認します。
3. [すべてリッスン] 設定が [はい] に設定されている場合は、[IP アドレス] タブに切り替え、Windows の下部までスクロールして [IPAll] 設定を見つけます。 TCP 動的ポートに含まれている現在の値を削除し、[TCP ポート] フィールドで目的の値を設定します。 [OK] を選択し、設定を有効にするために SQL Server インスタンスを再起動します。
4. [すべてリッスン] 設定が [いいえ] に設定されている場合は、[IP アドレス] タブに切り替えて、IP1、IP2 に表示される各 IP アドレスを確認します。 有効な IP アドレスの場合は、[TCP 動的ポート] フィールドに含まれる現在の値を削除し、[TCP ポート] フィールドに目的の値を設定します。 [OK] を選択し、設定を有効にするために SQL Server インスタンスを再起動します。
詳細については、「特定の TCP ポートでリッスンするようにサーバーを構成する」を参照してください。重複する SPN 同じ SPN が Active Directory の異なるアカウントに登録されていることがあります。 1. [修正] ボタンを選択して [警告] ダイアログ ボックスで情報を表示し、不足している SPN を Active Directory に追加できる場合は [はい] を選択します。
2. ドメイン アカウントに Active Directory の更新に必要なアクセス権限がある場合は、正しくない SPN が削除されます。
3. ドメイン アカウントに Active Directory の更新に必要なアクセス権限がない場合は、[生成] ボタンまたは [すべて生成] ボタンを使用して重複する SPN を削除するために必要なスクリプトを生成し、Active Directory 管理者に渡します。 SPN が削除されたら、KCM をもう一度実行して、SPN の問題が解決されたことを確認します。注:
KCM を開始するドメイン アカウントに Active Directory の SPN を操作する権限がない場合は、[SPN スクリプト] 列にある対応する [生成] ボタンまたは [すべて生成] ボタンを使用して必要なコマンドを生成し、Active Directory 管理者と連携して KCM が識別した問題を修正します。
KCM で特定されたすべての問題を修正したら、ツールをもう一度実行します。 他の問題が何も報告されないことを確認し、接続を再試行します。 ツールでまだ問題が報告される場合は、前の手順を繰り返します。
Kerberos Configuration Manager を使用せずにエラーを修正する
KCM を使用できない場合は、次の手順に従います。
手順 1: ping コマンドを使用して名前解決を確認する
Kerberos 認証を成功させる重要な要因は、ネットワーク上に有効な DNS 機能があることです。
Ping コマンド プロンプト ユーティリティを使用すると、クライアントとサーバーでこの機能を確認できます。 クライアント コンピューターで次のコマンドを実行し、SQL Server を起動しているサーバーの IP アドレスを取得します (コンピューターの名前は SQLServer1 です)。
ping sqlserver1
Ping ユーティリティで SQLServer1 の完全修飾 DNS を解決できるかどうかを確認するには、次のコマンドを実行します。
ping -a <IPAddress>
以下に例を示します。
C:\>ping SQLSERVER1
Pinging SQLSERVER1 [123.123.123.123] with 32 bytes of data:
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Ping statistics for 123.123.123.123:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\>ping -a 123.123.123.123
Pinging SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] with 32 bytes of data:
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Ping statistics for 123.123.123.123:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\>
SQL Server を実行しているコンピューターで正しい完全修飾 DNS がコマンド ping -a <IPAddress> で解決された場合、クライアント側での解決も成功します。
詳細な診断については、Test-NetConnection コマンドレットまたは Test-Connection コマンドレットを使用して、コンピューターにインストールされている PowerShell のバージョンに応じて TCP 接続をテストします。 PowerShell のコマンドレットの詳細については、「コマンドレットの概要」を参照してください。
注:
名前解決方法には、DNS、WINS、Hosts ファイル、Lmhosts ファイルが含まれるでしょう。 名前解決の問題とトラブルシューティングの詳細については、次のリンクを参照してください。
SQL Server 構成マネージャーと SQL Server クライアント ネットワーク ユーティリティに、宛先 SQL Server のエイリアスが存在するかどうかを確認します。 そのようなエイリアスが存在する場合は、正しく構成されていることを確認するために、サーバー名、ネットワーク プロトコル、ポート番号などを確認します。 SQL Server エイリアス を使用すると、予期しない SPN が生成される可能性があります。 これにより、SPN が見つからない場合は NTLM 資格情報が生成され、別のサーバーの SPN と誤って一致した場合は SSPI エラーが発生します。
手順 2: ドメイン間の通信を確認する
サインインするドメインが、SQL Server を実行しているサーバーのドメインと通信できることを確認します。 ドメインでは、正しく名前を解決できることも必要です。
SQL Server サービスのスタートアップ アカウントと同じドメイン アカウントとパスワードで、Windows にサインインできることを確認します。 たとえば、次のいずれかの状況で SSPI エラーが発生する可能性があります。
- ドメイン アカウントがロックアウトされています。
- アカウントのパスワードが変更された後、SQL Server サービスを再起動しませんでした。
ログインするドメインが、SQL Server を実行しているサーバーのドメインと異なる場合は、ドメイン間の信頼関係を確認します。
サーバーが属しているドメインと、接続に使用するドメイン アカウントが同じフォレスト内にあるかどうかを確認します。 SSPI を機能させるには、この手順が必要です。
手順 3: SQLCHECK ツールと Setspn ツールを使用して SQL Server SPN を確認する
SQL Server コンピューターにローカルでサインインし、管理者アクセス権を持つ場合は、 SQLCHECK を使用します。 SQLCheck では、1 つのファイルでトラブルシューティングに必要なほとんどの情報が提供されます。 ツールの使用方法と収集する情報の詳細については、ツールのホーム ページを参照してください。 推奨される 前提条件 とチェックリストのページを確認することもできます。 出力ファイルを生成したら、出力ファイルの SQL Server情報 セクションで、SQL Server インスタンスの SPN 構成を確認します。
出力例:
Suggested SPN Exists Status
---------------------------------------------------------- ------ -------------------
MSSQLSvc/testsqlsvr.corp.com:2000 True Okay
MSSQLSvc/testsqlsvr.corp.com True Okay
MSSQLSvc/testsqlsvr:2000 False SPN does not exist.
MSSQLSvc/testsqlsvr False SPN does not exist.
上記の出力を使用して、次の手順 (以下の例を参照) を決定し、 Setspn ツール を使用して SPN の問題を修正するために必要な修復アクションを実行します。
| シナリオ | 提案されているアクション |
|---|---|
| SPN が存在しない | SQL Server サービス アカウントに必要な SPN を追加します。 |
| SPN の重複 | 正しくないアカウントで SQL サービスに登録されている SPN を削除します。 |
| 正しくないアカウントの SPN | 正しくないアカウントで SQL Service に登録されている SPN を削除し、正しいサービス アカウントに SPN を登録します。 |
| 正しくない SPN が登録されている | 正しくない SPN を削除し、正しい SPN を登録します。 |
注:
SQLCHECK ツールの出力ファイルの [SQL Server 情報 ] セクションを確認して、SQL Server インスタンスのサービス アカウントを見つけることができます。
Setspn は、Active Directory の SPN の読み取り、追加、変更、または削除に役立つ新しいバージョンの Windows の組み込みツールです。 このツールを使用して、SQL Server SPN が Kerberos 接続のサービス プリンシパル名の登録に従って構成されていることを確認できます。 詳細については、 Setspn ツール と使用方法の例を参照してください。
SQL Serverが SPN を自動的に登録するシナリオと、SPN の手動登録が必要なシナリオの詳細については、Kerberos 接続のサービス プリンシパル名を登録するを参照してください。
手順 4: リンク サーバー上のスタートアップ アカウントSQL Serverのアカウントのアクセス許可を確認する
リンク サーバーの セキュリティ ページで認証オプションとして偽装を使用する場合は、受信した資格情報をリモート SQL Serverに渡すためにSQL Serverが必要です。 リンク サーバーが定義されているSQL Serverスタートアップ アカウントには、Active Directory で委任権が割り当てられているアカウントが信頼されている必要があります。 詳細については、 コンピューターアカウントとユーザー アカウントを委任に対して信頼できるようにするを参照してください。
注:
この手順は、リンク サーバー クエリに関連する問題のトラブルシューティングを行う場合にのみ必要です。