"SSPI コンテキストを生成できません" エラー メッセージのトラブルシューティング方法

文書翻訳 文書翻訳
文書番号: 811889 - 対象製品
中小企業のお客様は、中小企業向けサポートサイトで問題解決コンテンツや学習リソースもご利用ください。
すべて展開する | すべて折りたたむ

目次

概要

この資料では、"SSPI コンテキストを生成できません" というエラー メッセージの一般的な発生原因のトラブルシューティングを行う方法について、手順を追って説明します。このエラー メッセージは、次の条件に該当する場合に表示されることがあります。
  • SQL Server に接続しています。
  • 統合セキュリティを使用しています。
  • Kerberos を使用して、セキュリティの委任が行われています。

Kerberos の用語とサービス プリンシパル名について

クライアント コンピュータの SQL Server ドライバは、SQL Server を実行しているコンピュータに正しく接続するために、統合セキュリティを使用してユーザー アカウントの Windows セキュリティ トークンを使用します。Windows セキュリティ トークンは、クライアントから SQL Server を実行しているコンピュータに委任されます。以下のいずれかの構成を使用することによって、ユーザーのセキュリティ トークンがあるコンピュータから別のコンピュータに委任されるときに、SQL Server ドライバがこの委任を実行します。
  • 名前付きパイプ経由の NTLM (SSPI を使用しない)
  • SSPI を使用した TCP/IP 経由の NTLM
  • SSPI を使用した TCP/IP 経由の Kerberos
SSPI (Security Support Provider Interface) は、TCP/IP ソケットなどの任意の汎用データ トランスポート層経由で委任と相互認証を可能にする Windows API のセットです。したがって、Windows オペレーティング システムを実行するコンピュータは、SSPI を使用することにより、未加工のデータ バイトを送信できる任意のトランスポート層経由で、あるコンピュータから別のコンピュータにユーザー セキュリティ トークンを安全に委任できます。

"SSPI コンテキストを生成できません" というエラーが発生するのは、SSPI が Kerberos を使用して TCP/IP 経由で委任を行うときに、SQL Server を実行している委任先のコンピュータにユーザー セキュリティ トークンを正しく委任するために必要な操作を Kerberos が完了できない場合です。

SSPI により NTLM または Kerberos が選択される理由

Kerberos は、"SPN (サービス プリンシパル名)" という識別子を使用します。SPN は、ネットワーク サーバー リソース内の何らかのインスタンスのドメイン一意識別子またはフォレスト一意識別子と考えることができ、Web サービス、SQL サービス、または SMTP サービスに対して割り当てることができます。また、同一の物理コンピュータ上の複数の Web サービス インスタンスに、1 つの一意 SPN を割り当てることもできます。

SQL Server の SPN は以下の要素で構成されます。
  • ServiceClass : これにより、サービスの一般的なクラスが識別されます。SQL Server の場合は、常に MSSQLSvc です。
  • Host : これは、SQL Server を実行しているコンピュータの完全修飾ドメイン名 DNS です。
  • Port : これは、サービスが受信待ちするポート番号です。
たとえば、SQL Server を実行しているコンピュータの一般的な SPN は次のとおりです。
MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433
既定のインスタンスの SPN の書式、および名前付きインスタンスの SPN の書式には、違いはありません。SPN は、ポート番号によって特定のインスタンスに関連付けられます。

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

クライアントの SQL Server ドライバが SQL Server を実行しているコンピュータの完全修飾 DNS を解決するときに、対応する DNS を使用してこのコンピュータの SPN が形成されます。そのため、WinSock が IP アドレスやホスト名を完全修飾 DNS に解決する方法に関して何らかの問題がある場合、SQL Server ドライバにより SQL Server を実行しているコンピュータに対して無効な SPN が作成される可能性があります。

たとえば、完全修飾 DNS が以下のように解決される場合、クライアント側 SQL Server ドライバによって無効な SPN が形成される可能性があります。
  • 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 を検索しますが、その SPN は見つからないためです。SPN が見つからなかった場合、Kerberos 認証は実行されません。SPN が見つからなかった時点で、SSPI 層は NTLM 認証モードに切り替わり、ログオンに NTLM 認証が使用されて、通常はログオンが成功します。SQL Server ドライバにより有効な SPN が形成され、その SPN が適切なコンテナに割り当てられていない場合、SQL Server ドライバではその SPN を使用することができないため、"SSPI コンテキストを生成できません" というエラー メッセージが生成されます。SQL Server の起動アカウントがローカル システム アカウントである場合、適切なコンテナはコンピュータ名です。それ以外のアカウントの場合は、SQL Server の起動アカウントが適切なコンテナです。認証では最初に検出された SPN を使用するため、不適切なコンテナに割り当てられた SPN が存在しないことを確認してください。つまり、各 SPN は 1 つのコンテナにのみ割り当てられる必要があります。

Kerberos 認証が正しく行われるには、ネットワーク上で DNS が正常に機能することが重要な要因です。DNS が正常に機能していることは、クライアントおよびサーバーで Ping コマンド ライン ユーティリティを使用することによって確認できます。クライアント コンピュータでは、以下のコマンドを使用して、SQL Server を実行しているサーバーの IP アドレスを取得します (ここでは、SQL Server を実行しているコンピュータの名前を 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:\>
コマンド ping -a IPAddress によって、SQL Server を実行しているコンピュータの完全修飾 DNS が正しく解決される場合は、クライアント側の解決も正しく行われます。

SQL Server サービス プリンシパル名の作成

これは、Kerberos と SQL Server との対話的処理の重要な部分の 1 つです。SQL Server では、LocalSystem アカウント、ローカル ユーザー アカウント、またはドメイン ユーザー アカウントのいずれかで SQL Server サービスを実行できます。SQL Server サービス インスタンスは起動時に、DsWriteAccountSpn API 呼び出しを使用して、独自の SPN を Active Directory に登録しようとします。この呼び出しが正しく行われなかった場合は、以下の警告がイベント ビューアに記録されます。

ソース : MSSQLServer
イベント ID : 19011
説明 : SuperSocket 情報 : (SpnRegister) : エラー 8344

DsWriteAccountSpn 関数の詳細については、次のマイクロソフト Web サイトを参照してください。
http://msdn2.microsoft.com/en-us/library/ms676056.aspx

簡単な説明

LocalSystem アカウントで SQL Server サービスを実行すると、SPN が自動的に登録され、Kerberos と SQL Server を実行しているコンピュータとの対話的な処理は正常に実行されます。しかし、ドメイン アカウントまたはローカル アカウントで SQL Server サービスを実行した場合、これらのアカウントには独自の SPN を設定するための権限がないため、SPN の作成は通常失敗します。SPN が正しく作成されないと、SQL Server を実行しているコンピュータに対して SPN がセットアップされないことになります。SQL Server サービス アカウントとしてドメイン管理者アカウントを使用してテストすると、SPN が正しく作成されます。これは、SPN を作成するために必要なドメイン管理者レベルの資格情報が存在するためです。

セキュリティ上の危険を回避するために、SQL Server サービスの実行にドメイン管理者アカウントを使用することはないため、SQL Server を実行しているコンピュータは独自の SPN を作成できません。このため、SQL Server を実行しているコンピュータに接続する際に Kerberos を使用する場合は、そのコンピュータ用の SPN を手動で作成する必要があります。SQL Server をドメイン ユーザー アカウントまたはローカル ユーザー アカウントで実行する場合がこれに該当します。作成した SPN は、その特定のコンピュータ上の SQL Server サービスのサービス アカウントに割り当てる必要があります。SQL Server を実行するコンピュータがローカル システムで起動されていない限り、SPN をコンピュータ コンテナに割り当てることはできません。SPN は必ず 1 つだけ存在し、適切なコンテナに割り当てられる必要があります。通常、適切なコンテナは、現在の SQL Server サービス アカウントですが、このアカウントは、ローカル システムのコンピュータ アカウントです。

ドメインの確認

ログオンするドメインが、SQL Server を実行しているコンピュータが所属するドメインと通信できることを確認します。また、ドメイン内で適切に名前が解決される必要があります。
  1. ログオンするドメインが、SQL Server を実行しているコンピュータが所属するドメインと同一の場合は、Windows 認証を使用して SQL Server にログオンします。認証が失敗する場合は、Windows アカウントまたはドメイン アカウントの問題を解決する必要があります。セキュリティ管理者またはネットワーク管理者に問い合わせて、Windows アカウントまたはドメイン アカウントに適切なアクセス許可が付与されていることを確認してください。
  2. ログオンするドメインが、SQL Server を実行しているコンピュータが所属するドメインと異なる場合は、ドメイン間の信頼関係を確認します。
  3. サーバーが所属するドメインと、接続に使用するドメイン アカウントが同じフォレスト内にあるかどうかを確認します。これは、SSPI が機能するための必須条件です。
  4. SQL Server を起動するときのサービス アカウントに対して、Active Directory ユーザーとコンピュータで [アカウントは委任に対して信頼されている] を有効にします。
  5. Windows 2000 リソース キットの Manipulate Service Principal Names for Accounts (SetSPN.exe) ユーティリティを使用します。Windows 2000 ドメイン管理者アカウントまたは Windows Server 2003 ドメイン管理者アカウントでは、このユーティリティを使用して、サービスおよびアカウントに割り当てられた SPN を管理できます。SQL Server の場合、SPN が 1 つだけ必要です。この SPN は、適切なコンテナに割り当てられる必要があり、ほとんどの場合は、現在の SQL Server サービス アカウントに割り当てられ、SQL Server がローカル システム アカウントで起動されている場合は、コンピュータ アカウントに割り当てられます。LocalSystem アカウントでログオンしている間に SQL Server を起動すると、SPN が自動的にセットアップされます。ただし、ドメイン アカウントを使用して SQL Server を起動する場合、または SQL Server の起動に使用するアカウントを変更する場合は必ず、SetSPN.exe を実行して有効期限の切れた SPN を削除して、有効な SPN を追加する必要があります。詳細については、次のマイクロソフト Web サイトで、SQL Server 2000 Books Online の「セキュリティ アカウントの委任」を参照してください。
    http://msdn.microsoft.com/library/ja/?url=/library/ja/adminsql/ad_security_2gmm.asp?frame=true
    Windows 2000 リソース キットの詳細については、次のマイクロソフト Web サイトを参照してください。
    http://www.microsoft.com/japan/technet/prodtechnol/windows2000serv/proddocs/reskit/default.mspx
  6. 名前の解決が正しく行われることを確認します。名前の解決方法には、DNS、WINS、HOSTS ファイル、LMHOSTS ファイルなどがあります。 名前解決の問題およびトラブルシューティングの関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
    169790 基本的な TCP/IP の問題を解決する方法
  7. Active Directory に関するアクセシビリティとファイアウォールの問題のトラブルシューティング方法の関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
    291382 Windows 2000 および Windows Server 2003 の DNS に関してよく寄せられる質問
    224196 [NT] ポートへの Active Directory レブリケーション トラフィックを制限できる

SQL Server インスタンスの SPN を動的に作成するように SQL Server サービスを構成する方法

SPN を動的に作成するように SQL Server サービスを構成するには、Active Directory ディレクトリ サービスでアカウントのアクセス制御設定を変更する必要があります。SQL Server サービス アカウントに対して、"servicePrincipalName の読み取り" アクセス許可および "servicePrincipalName の書き込み" アクセス許可を付与する必要があります。

警告 : Active Directory サービス インターフェイス (ADSI) Edit スナップイン、LDP ユーティリティ、またはその他の LDAP 3 クライアントを使用して、Active Directory オブジェクトの属性に不適切な変更を加えると、深刻な問題が発生することがあります。最悪の場合、Microsoft Windows Server 2003、Microsoft Windows 2000 Server、Microsoft Exchange Server 2003、Microsoft Exchange 2000 Server のいずれか、または Windows と Exchange の両方の再インストールが必要になることがあります。マイクロソフトは、Active Directory オブジェクトの属性の誤った変更により発生した問題に関して、一切責任を負わないものとします。これらの属性の変更は、自己の責任において行ってください。

: SQL Server の起動アカウントに適切なアクセス許可およびユーザー権利を付与するには、ドメイン管理者としてログオンしているか、この作業を行うようドメイン管理者に要求する必要があります。

SPN を動的に作成するように SQL Server サービスを構成するには、以下の手順を実行します。
  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。Adsiedit.msc と入力し、[OK] をクリックします。
  2. ADSI Edit スナップインで、[Domain [DomainName]]、[DC=RootDomainName]、[CN=Users] の順に展開し、[CN= AccountName] を右クリックして、[プロパティ] をクリックします。

    • DomainName には、ドメインの名前が入ります。
    • RootDomainName には、ルート ドメインの名前が入ります。
    • AccountName には、SQL Server サービスを開始するために指定するアカウントが入ります。
    • ローカル システム アカウントを指定して SQL Server サービスを開始する場合、AccountName には Microsoft Windows にログオンするために使用するアカウントが入ります。
    • ドメイン ユーザー アカウントを指定して SQL Server サービスを開始する場合、AccountName にはドメイン ユーザー アカウントが入ります。
  3. [CN= AccountName Properties] ダイアログ ボックスの [セキュリティ] タブをクリックします。
  4. [セキュリティ] タブの [詳細設定] をクリックします。
  5. [AccountName のセキュリティの詳細設定] ダイアログ ボックスで、[SELF] が [アクセス許可エントリ] ボックスの一覧に表示されていることを確認します。

    [SELF] が一覧に表示されていない場合は、[追加] をクリックし、SELF を追加します。
  6. [アクセス許可エントリ] ボックスの一覧の [SELF] をクリックし、[編集] をクリックします。
  7. [AccountName のアクセス許可エントリ] ダイアログ ボックスの [プロパティ] タブをクリックします。
  8. [プロパティ] タブで、[適用先] ボックスの一覧の [このオブジェクトのみ] をクリックし、[アクセス許可] で以下のチェック ボックスがオンになっていることを確認します。
    • servicePrincipalName の読み取り
    • servicePrincipalName の書き込み
  9. [OK] を 3 回クリックし、ADSI Edit スナップインを終了します。
この手順のサポートが必要な場合は、Active Directory 担当の製品サポートに問い合わせ、この「サポート技術情報」 (Microsoft Knowledge Base) の資料のことをお知らせください。

サーバー環境の確認

SQL Server がインストールされているコンピュータで、いくつかの基本的な設定を確認します。
  1. Windows クラスタリングを実行している Windows 2000 ベースのコンピュータでは、Windows 2000 に Service Pack 3 (以降) を適用しないと、Kerberos がサポートされません。そのため、SQL Server のクラスタ化されたインスタンスで SSPI 認証の使用を試みても成功しません。 関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
    235529 Windows 2000 ベースのサーバー クラスタでの Kerberos サポート
  2. サーバーで Windows 2000 Service Pack 1 (SP1) が実行されていることを確認します。 Windows 2000 ベースのサーバーでの Kerberos サポートの関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
    267588 SQL Server 2000 に接続するときにエラー メッセージ "SSPI コンテキストを生成できません" が表示される
  3. クラスタにおいて、SQL Server サービス、SQL Server エージェント サービス、またはフルテキスト検索サービスの開始に使用するアカウントで、パスワード変更などの変更を行った場合は、次の「サポート技術情報」 (Microsoft Knowledge Base) の資料に記載されている手順を実行します。
    239885 クラスタ化された SQL Server コンピュータのサービス アカウントを変更する方法
  4. SQL Server の起動に使用するアカウントに適切なアクセス許可が付与されているかどうかを確認します。ローカルの Administrators グループのメンバではないアカウントを使用している場合は、以下の SQL Server Books Online の「Windows サービス アカウントの設定」で、このアカウントに必要なアクセス許可の詳細な一覧を参照してください。
    http://msdn.microsoft.com/library/ja/?url=/library/ja/instsql/in_overview_6k1f.asp?frame=true

クライアント環境の確認

クライアントで、以下の項目を確認します。
  1. クライアントに NTLM セキュリティ サポート プロバイダがインストールされ、有効になっていることを確認します。 関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
    269541 SQL Server への接続時に Windows NT LM Security Support Provider レジストリ キーが見つからない場合、エラー メッセージ "SSPI コンテキストを生成できません" が表示される
  2. キャッシュされた資格情報を使用しているかどうかを調べます。キャッシュされた資格情報を使用してクライアントにログオンしている場合、キャッシュされた資格情報が使用されるのを防ぐため、ドメイン コントローラに接続できるときにログオフして、再度ログオンします。 キャッシュされた資格情報を使用しているかどうかを確認する方法の関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
    242536 ドメインのキャッシュされた資格情報でログオンするときに警告が通知されない
  3. クライアントとサーバーの日付が有効であることを確認します。日付が大きく異なっているときは、資格情報が無効である可能性があります。
  4. SSPI では Security.dll という名前のファイルを使用します。他のアプリケーションによってこの名前のファイルがインストールされている場合は、実際の SSPI ファイルではなく、他のファイルが使用されている可能性があります。 関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
    253577 エラー : 80004005 - MS ODBC SQL Server Driver Cannot Initialize SSPI Package
  5. クライアントのオペレーティング システムが Microsoft Windows 98 の場合、クライアントに Microsoft ネットワーク クライアント コンポーネントをインストールする必要があります。 関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
    267550 [BUG] TCP/IP を使用して SQL Server に接続するときに "アサートに失敗" というメッセージが表示される

クライアント ネットワーク ユーティリティの確認

Microsoft Data Access Components (MDAC) と共に提供されているクライアント ネットワーク ユーティリティ (CNU) を使用して、SQL Server を実行しているコンピュータとの接続を構成します。接続を構成するために、MDAC Cliconfg.exe CNU ユーティリティを使用できます。
  1. [全般] タブのプロトコルの定義方法は、MDAC のバージョンによって異なります。以前のバージョンの MDAC では、"デフォルト" のプロトコルを選択できます。最新版の MDAC では、SQL Server への接続時に 1 つ以上のプロトコルを有効にでき、そのうちの 1 つのプロトコルを先頭に指定することができます。SSPI は TCP/IP のみに適用されるため、エラーを回避するために名前付きパイプなどの別のプロトコルを使用できます。
  2. CNU の [別名] または [変更] タブで、接続先のサーバーに別名が定義されているかどうかを確認します。サーバーの別名が定義されている場合は、コンピュータから SQL Server への接続の構成に関する設定を確認します。別名サーバーを削除して動作が変化するかどうかを確認することによって、この設定を確認できます。
  3. CNU で別名サーバーが定義されていない場合は、接続しているサーバーの別名を追加します。別名を追加するときは、プロトコルも明示的に定義し、オプションで IP アドレスやポートも定義します。

情報を収集して Microsoft Product Support Services (PSS) に問い合わせる

この資料のトラブルシューティング手順を使用して問題の原因を判断できない場合は、以下の情報を収集して、Microsoft Product Support Services (PSS) に問い合わせてください。

Microsoft Product Support Services の電話番号一覧およびサポート料金については、次のマイクロソフト Web ページを参照してください。
http://support.microsoft.com/contactus/?ws=support
  1. SQL Server から sqldiag レポートを生成します。詳細については、SQL Server Books Online の「sqldiag ユーティリティ」を参照してください。
  2. クライアントでエラーのスクリーンショットを取ります。
  3. SQL Server に接続できないノードで、コマンド プロンプトから次のコマンドを入力します。
    net start > started.txt
    コマンドを実行したディレクトリに、Started.txt という名前のファイルが生成されます。
  4. クライアント コンピュータで、次のレジストリ キーの下にあるレジストリ キーの値を保存します。
    HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSSQLSERVER\CLIENT\CONNECTTO
  5. クラスタ化された環境では、クラスタの各ノードで次のレジストリ キーの値を取得します。
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\LMCompatibilityLevel
  6. クラスタ化された環境では、クラスタの各クラスタ サーバー ノードに次のレジストリ キーが存在するかどうかを確認します。
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTLMSsp
  7. クライアントから UNC 名 (または、クラスタでの SQL ネットワーク名) を使用して SQL Server に接続した結果をキャプチャします。
  8. クライアントからコンピュータ名 (または、クラスタでの SQL ネットワーク名) に Ping を行った結果をキャプチャします。
  9. SQL Server の各サービス (MSSQLServer、SQLServerAgent、MSSearch) の開始に使用しているユーザー アカウントの名前を保存します。
  10. サポート担当者は、SQL Server が混合認証または Windows 認証のみのいずれで構成されているかを把握する必要があります。
  11. 同じクライアントから SQL Server 認証を使用して、SQL Server を実行しているコンピュータに接続できるかどうかを確認します。
  12. 名前付きパイプ プロトコルを使用して接続できるかどうかを確認します。

SQL Server のサービス プリンシパル名を手動でセットアップする方法

SQL Server のサービス プリンシパル名を手動でセットアップする方法の関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
319723 SQL Server で Kerberos 認証を使用する方法


SSPI (Security Support Provider Interface) は、Kerberos 認証に使用される Microsoft Windows NT セキュリティに対するインターフェイスで、NTLM セキュリティ サポート プロバイダの認証手法をサポートします。認証は、Windows ドメインにログオンするときに、オペレーティング システム レベルで行われます。Kerberos 認証は、Kerberos が有効で、Active Directory を使用している Windows 2000 ベースのコンピュータのみで利用できます。

SSPI は、Windows 認証を使用して行われる TCP/IP 接続のみで使用されます (Windows 認証は、信頼関係接続または統合セキュリティとも呼ばれます)。SSPI は名前付きパイプ接続やマルチプロトコル接続では使用されません。したがって、クライアントから TCP/IP 以外のプロトコル経由で接続するように構成することによって、問題を回避できます。

SQL Server クライアントが TCP/IP ソケット経由で統合セキュリティを使用して、SQL Server を実行しているリモート コンピュータに接続を試みると、SQL Server クライアント ネットワーク ライブラリは SSPI API を使用してセキュリティの委任を行います。SQL Server ネットワーク クライアント (Dbnetlib.dll) は AcquireCredentialsHandle 関数に対して呼び出しを行い、pszPackage パラメータに "negotiate" を渡します。これは、元になるセキュリティ プロバイダに委任のネゴシエートを行うことを通知するものです。この状況でのネゴシエートは、Windows ベースのコンピュータで Kerberos 認証または NTLM 認証のいずれかを試みることを意味します。つまり、SQL Server を実行している委任先のコンピュータが正しく構成された SPN に関連付けられている場合、Windows は Kerberos 委任を使用します。それ以外の場合、Windows は NTLM 委任を使用します。

: SQL Server のいずれかのサービス (MSSQLServer、SQLServerAgent、MSSearch) の開始に、"SYSTEM" という名前のアカウントを使用していないことを確認してください。キーワード SYSTEM は、キー配布センター (KDC) と競合する原因になる可能性があります。

関連情報

Kerberos および SSPI セキュリティの動作の関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
266080 Kerberos に関してよく寄せられる質問
231789 Windows 2000 のローカル ログオン プロセス
304161 SSPI 相互認証がクライアント側では示されるが、サーバー側で示されない
232179 Windows 2000 における Kerberos の管理
230476 Windows 2000 における Kerberos 関連のよくあるエラーについて
262177 Kerberos イベント ログを有効にする方法
277658 [PRB] SQL Server SPN が登録されている NetBIOS 名とドメイン名が異なると Setspn が失敗する
244474 Windows Server 2003、Windows XP、および Windows 2000 で Kerberos に UDP ではなく TCP を使用するように強制する方法
326985 [HOWTO] IIS の Kerberos に関する問題のトラブルシューティング
Microsoft SQL Server 2000 のセキュリティに関するホワイト ペーパーを参照するには、次のマイクロソフト Web サイトにアクセスしてください。
http://www.microsoft.com/japan/technet/prodtechnol/sql/2000/maintain/sp3sec00.mspx

プロパティ

文書番号: 811889 - 最終更新日: 2013年7月16日 - リビジョン: 22.1
この資料は以下の製品について記述したものです。
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 64-bit Edition
キーワード:?
kbsqlmanagementtools kbhowtomaster kbhowto KB811889
Microsoft Knowledge Base の免責: Microsoft Knowledge Baseに含まれている情報は、いかなる保証もない現状ベースで提供されるものです。Microsoft Corporation及びその関連会社は、市場性および特定の目的への適合性を含めて、明示的にも黙示的にも、一切の保証をいたしません。さらに、Microsoft Corporation及びその関連会社は、本文書に含まれている情報の使用及び使用結果につき、正確性、真実性等、いかなる表明・保証も行ないません。Microsoft Corporation、その関連会社及びこれらの権限ある代理人による口頭または書面による一切の情報提供またはアドバイスは、保証を意味するものではなく、かつ上記免責条項の範囲を狭めるものではありません。Microsoft Corporation、その関連会社 及びこれらの者の供給者は、直接的、間接的、偶発的、結果的損害、逸失利益、懲罰的損害、または特別損害を含む全ての損害に対して、状況のいかんを問わず一切責任を負いません。(Microsoft Corporation、その関連会社 またはこれらの者の供給者がかかる損害の発生可能性を了知している場合を含みます。) 結果的損害または偶発的損害に対する責任の免除または制限を認めていない地域においては、上記制限が適用されない場合があります。なお、本文書においては、文書の体裁上の都合により製品名の表記において商標登録表示、その他の商標表示を省略している場合がありますので、予めご了解ください。

フィードバック

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com