Windows 認証を使用して接続するときに "SSPI コンテキストを生成できません" エラー SQL Server

適用対象:   SQL Server
元の KB 番号: 811889

注意

トラブルシューティングを開始する前に、 前提条件 を確認し、チェックリストを確認することをお勧めします。

Windows 認証を使用してSQL Server インスタンスをリモートで接続すると、次のエラー メッセージが表示されます。

ターゲット プリンシパル名が正しくありません。 SSPI コンテキストを生成できません。

よく寄せられる質問

SSPI とは

セキュリティ サポート プロバイダー インターフェイス (SSPI) は、TCP/IP ソケットなど、任意の汎用データ トランスポート層に対する委任と相互認証を許可する一連の Windows API です。 1 つ以上のソフトウェア モジュールは、実際の認証機能を提供します。 各モジュールはセキュリティ サポート プロバイダー (SSP) と呼ばれ、ダイナミック リンク ライブラリ (DLL) として実装されます。

Kerberos とは

Kerberos v5 プロトコルは業界標準のセキュリティ パッケージであり、Windows オペレーティング システムの 3 つのセキュリティ パッケージの 1 つです。 詳細については、「 セキュリティ サポート プロバイダー (SP)」を参照してください。

"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 Serverサービス SPN の登録の詳細については、「Kerberos 接続のサービス プリンシパル名を登録する」を参照してください。

SSPI で NTLM 認証または Kerberos 認証が使用されるのはなぜですか?

Windows 認証は、ユーザーがSQL Serverに対して認証するために推奨される方法です。 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 委任が使用されます。

Kerberos で問題が発生した後、接続が NTLM にフェールオーバーされないのはなぜですか?

クライアント上のSQL Server ドライバー コードでは、WinSock ネットワーク API を使用して、ドライバーがWindows 認証を使用してSQL Serverに接続するときに、サーバーの完全修飾 DNS を解決します。 この操作を実行するために、ドライバー コードは WinSock API と gethostbyaddr WinSock API を呼び出gethostbynameします。 統合セキュリティが使用されている場合、IP アドレスまたはホスト名がサーバーの名前として渡された場合でも、ドライバーはサーバーの完全修飾 DNS を解決しようとします。

クライアント上のSQL Server ドライバーがサーバーの完全修飾 DNS を解決すると、対応する DNS を使用してサーバーの SPN が形成されます。 そのため、WinSock によって IP アドレスまたはホスト名を完全修飾 DNS に解決する際に問題が発生すると、SQL Server ドライバーによってサーバーの無効な SPN が作成される可能性があります。

たとえば、クライアント側のSQL Server ドライバーは、次のように無効な SPN を解決するために完全修飾 DNS として使用できます。

  • MSSQLSvc/SQLSERVER1:1433
  • MSSQLSvc/123.123.123.123:1433
  • MSSQLSvc/SQLSERVER1.antartica.corp.mycompany.com:1433
  • MSSQLSvc/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に接続しているかどうかを判断する」を参照してください。

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 接続が失敗する理由には、SPN の構成ミス、名前解決の問題、SQL Serverサービススタートアップ アカウントの権限不足など、さまざまな理由があります。 Microsoft Kerberos Configuration Manager (KCM) は、エラーの原因を確認するのに役立つツールです。 KCM には、プロセス内で特定された問題を修正するためのオプションも用意されています。

KCM を使用してエラーを修正するには、次の手順に従います。

  1. 接続の問題があるコンピューターで、Kerberos Configuration Managerをダウンロードしてインストールします。

  2. %SystemDrive%:\Program Files\Microsoft\Kerberos Configuration Manager フォルダーから KerberosConfigMgr.exeを開始します。 次に、接続できないSQL Server コンピューターに接続するためのアクセス許可を持つドメイン アカウントを使用します。

  3. [接続] を選択し、SQL Server コンピューターで KCM を実行している場合は、シナリオに該当するサーバー名とその他の詳細を空白のままにします。 [ 接続 ] を選択して分析を実行します。 KCM が必要な情報の取得を完了すると、自動的に [SPN] タブに切り替わり、既定ではSQL Server、SQL Server Reporting Services、Analysis Services、AG リスナーの情報が表示されます。 このエラーのトラブルシューティングを行うには、SQL Serverを除くすべてをオフにします。

  4. [状態] 列を使用してツールから診断を確認し、関連する手順に従って問題を解決します。

    状態 詳細情報 操作
    Good チェックされた項目が正しく構成されています。 出力の次の項目に進むことができます。 アクションは必要ありません
    必要な SPN がありません この状態は、Active Directory のSQL Serverスタートアップ アカウントの [必須 SPN] 列で特定された SPN が見つからない場合に報告されます。 1. [ 修正] を選択して、[ 警告 ] ダイアログ ボックスの情報を確認します。
    2. [はい ] を選択して、不足している SPN を Active Directory に追加します。
    3. ドメイン アカウントに Active Directory を更新するために必要なアクセス許可がある場合は、必要な SPN が Active Directory に追加されます。
    4. ドメイン アカウントに Active Directory の更新に必要なアクセス許可がない場合は、すべて 生成 または 生成 を使用して、Active Directory 管理者が不足している SPN を追加するのに役立つスクリプトを生成します。
    5. SPN が追加されたら、Kerberos Configuration Managerをもう一度実行して、SPN の問題が解決されたことを確認します。
    Kerberos 構成を使用するには TCP を有効にする必要があります これは、クライアント コンピューターで TCP が有効になっていない場合に発生します。 SQL Server インスタンスの TCP/IP プロトコルを有効にするには、次の手順に従います。
    1. SQL Server 構成マネージャー コンソール ウィンドウでネットワーク構成SQL Server 展開します。
    2. コンソール ウィンドウで、[プロトコル<instance name>] を選択します。
    3. 詳細 ウィンドウで、 TCP/IP を右クリックし、[ 有効] を選択します。
    4. コンソール ウィンドウで、[SQL Server サービス] を選択します。
    5. 詳細 ウィンドウで、SQL Serverを右クリックし(<instance name>)、[再起動] を選択してSQL Server サービスを停止して再起動します。
    詳細については、「 サーバー ネットワーク プロトコルを有効または無効にする」を参照してください。
    動的ポート このメッセージは、動的ポート (既定の構成) を使用する名前付きインスタンスに表示されます。 Kerberos を使用してSQL Serverに接続する必要がある環境では、名前付きインスタンスを静的ポートに設定し、SPN を登録するときにそのポートを使用する必要があります。 静的ポートを使用するようにSQL Server インスタンスを構成するには、次の手順に従います。
    1. SQL Server 構成マネージャーの コンソール ウィンドウで、ネットワーク構成SQL Server 展開し、[プロトコル] <instance name>を展開し、[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 の更新に必要なアクセス許可がない場合は、[すべて生成] ボタンを使用して、Active Directory 管理者に渡して重複する SPN を削除できる必要なスクリプトを生成します。 SPN が削除されたら、KCM を再実行して、SPN の問題が解決されたことを確認します。

    注意

    KCM を開始するドメイン アカウントに Active Directory の SPN を操作する権限がない場合は、SPN スクリプト 列の下にある対応する [生成] または [すべて生成] ボタンを使用して、必要なコマンドを生成し、Active Directory 管理者と連携して KCM によって識別される問題を修正できます。

  5. KCM で特定されたすべての問題を修正したら、ツールを再実行します。 他の問題が報告されないようにしてから、接続を再試行してください。 ツールで問題が報告される場合は、前の手順を繰り返します。

Kerberos Configuration Managerを使用せずにエラーを修正する

KCM を使用できない場合は、次の手順に従います。

手順 1: ping コマンドを使用して名前解決を確認する

Kerberos 認証を成功させる主な要因は、ネットワーク上の有効な DNS 機能です。 コマンド プロンプト ユーティリティを使用して、クライアントとサーバーでこの機能を Ping 確認できます。 クライアント コンピューターで、次のコマンドを実行して、SQL Serverを実行しているサーバーの IP アドレスを取得します (コンピューターの名前はSQLServer1次のとおりです)。

ping sqlserver1

Ping ユーティリティが完全修飾 DNS を解決するかどうかを確認するには、次の SQLServer1コマンドを実行します。

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:\> 

コマンドping -a <IPAddress>が、SQL Serverを実行しているコンピューターの正しい完全修飾 DNS に解決されると、クライアント側の解決も成功します。

詳細な診断については、 Test-NetConnection コマンドレットまたは Test-Connection コマンドレットを使用して、コンピューターにインストールされている PowerShell バージョンに従って TCP 接続をテストします。 PowerShell コマンドレットの詳細については、「コマンドレットの 概要」を参照してください。

注意

名前解決方法には、DNS、WINS、Hosts ファイル、Lmhosts ファイルが含まれる場合があります。 名前解決の問題とトラブルシューティングの詳細については、次のリンクを参照してください。

SQL Server 構成マネージャーとSQL Serverクライアント ネットワーク ユーティリティに、宛先SQL Serverのエイリアスが存在するかどうかを確認します。 このようなエイリアスが存在する場合は、サーバー名、ネットワーク プロトコル、ポート番号などを確認して、正しく構成されていることを確認します。

手順 2: ドメイン間の通信を確認する

サインインするドメインが、SQL Serverを実行しているサーバーのドメインと通信できることを確認します。 ドメインには正しい名前解決も必要です。

  1. SQL Server サービススタートアップ アカウントと同じドメイン アカウントとパスワードを使用して Windows にサインインできることを確認します。 たとえば、次のいずれかの状況で SSPI エラーが発生する可能性があります。

    • ドメイン アカウントはロックアウトされています。
    • アカウントのパスワードが変更された後、SQL Server サービスを再起動しませんでした。
  2. ログオン ドメインが、SQL Serverを実行しているサーバーのドメインと異なる場合は、ドメイン間の信頼関係を確認します。

  3. サーバーが属しているドメインと、接続に使用するドメイン アカウントが同じフォレスト内にあるかどうかを確認します。 SSPI を機能させるには、この手順が必要です。

手順 3: SQLCheck ツールと Setspn ツールを使用してSQL SERVER SPN を確認する

SQL Server コンピューターにローカルでサインインし、管理者がアクセスできる場合は、Microsoft SQL Networking GitHub リポジトリの 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 を登録します。

注意

  • 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 でそのアカウントに委任権が割り当てられているアカウント が信頼されている 必要があります。 詳細については、「 コンピューターアカウントとユーザー アカウントを委任に対して信頼できるようにする」を参照してください。

注意

この手順は、リンク サーバー クエリに関連する問題のトラブルシューティングを行う場合にのみ必要です。

関連項目