web-dev-qa-db-ja.com

SQL一括挿入のKerberos委任（アクセスが拒否されました）

次の状況でSQLに一括挿入しようとすると、問題が発生します。

  • ワークステーションAで管理スタジオを実行する
  • サーバーBで実行されているSQL
  • サーバーCにあるファイルから一括アップロード

一括アップロードしようとすると、エラーが発生します

Cannot bulk load because the file <filename> could not be opened. Operating system error code 5(Access is denied.).

ここでダブルホップの問題があり、委任を整理する必要があることを認識しています。 SPNは次のようにSQL用に設定されています（SQLは別のポートで実行されています）。 SQLはドメインユーザーとして実行されており、SPNはそのアカウントにあります。

command: setspn -l domain\sqluser

result:
MSSQLSvc/WIN-D04V1IOTESN
MSSQLSvc/WIN-D04V1IOTESN.domain.local
MSSQLSvc/win-d04v1iotesn.domain.local:55037
MSSQLSvc/WIN-D04V1IOTESN:55037

また、SQLユーザーアカウントからCifsおよびHostのファイルサーバーへの委任を設定しましたが、役に立ちませんでした。

Kerberosロギングを有効にしましたが、イベントビューアに次のイベントが表示されています。

 A Kerberos Error Message was received:
     on logon session 
     Client Time: 
     Server Time: 14:44:10.0000 8/9/2011 Z
     Error Code: 0xe KDC_ERR_ETYPE_NOTSUPP
     Extended Error: 
     Client Realm: 
     Client Name: 
     Server Realm: domain.LOCAL
     Server Name: krbtgt/domain.LOCAL
     Target Name: krbtgt/[email protected]
     Error Text: 
     File: 9
     Line: efb
     Error Data is in record data.

それで、私がここで欠けているものについて何か考えはありますか？私は以前にこの種の委任を機能させたことがありますが、常にデフォルトポートでSQLを使用していますが、それは影響を与える可能性がありますか？

編集

私は今、最初のエラーと一緒にこのケルボールエラーを見ています：

A Kerberos Error Message was received:
 on logon session 
 Client Time: 
 Server Time: 15:4:10.0000 8/9/2011 Z
 Error Code: 0xe KDC_ERR_ETYPE_NOTSUPP
 Extended Error: 
 Client Realm: 
 Client Name: 
 Server Realm: domain.LOCAL
 Server Name: krbtgt/domain.LOCAL
 Target Name: krbtgt/[email protected]
 Error Text: 
 File: 9
 Line: efb
 Error Data is in record data.
sql-serverkerberosdelegation
4
Sam Cogan

コメントから、ドメインログインを使用してSQLに接続しているため、SQLはファイル共有に接続するときにユーザーになりすまそうとしています。ドメインアカウントにこのための委任を設定していない場合、失敗します。

SQLログインとして接続されたストアドプロシージャを実行すると、SQLは、実行元のドメインサービスアカウントを使用しようとします。このアカウントに対して、既に委任を設定していると言います。

ドメインサービスアカウントを使用してクエリウィンドウに接続すると、その委任が既に構成されているため、SQLが機能するはずです。自分のドメインアカウントのファイルサーバーへの委任信頼を設定すると、ファイルサーバーが機能し始めます。

1
squillman

SPNはSQLServerに対して正しいように見えます。正しいSPNがファイルサーバーに登録されていますか？

SQL ServerへのKerberos認証を台無しにする可能性があるもう1つのことは、DNSの問題です。 SQLクライアントがサーバーのアドレスに対して逆DNSルックアップを実行し、その名前を使用してSPNを形成することをどこかで読みました。

私はあなたがすでにこれらのステップの多くを行ったことを知っています、しかしこれはあなたがする必要があるすべてであるはずです。
DNS解決がSQLサーバーとファイルサーバーの両方で正しく機能していることを確認します。
SQLServerのSPNを登録します。重複するSPNがないことを確認してください。 SQL 2008のsetspnは、このチェックを実行できます。
ファイルサーバーのSPNを登録します。重複がないことを確認してください。
SQLServerサービスアカウントで「委任に対して信頼されている」を有効にします。
また、アカウントが削除不可としてマークされていないことを確認してください。 （それは一言ですか？）

それを機能させることができない場合は、一括挿入を解除するSQLエージェントジョブを設定できます。次に、ジョブを実行するように構成したアカウントで実行されます。

1
pipTheGeek

エラーメッセージにクライアントの時間がないので、私は疑わしいです。クライアントの時刻とサーバーの時刻の差が大きすぎると、Kerberos認証は失敗します。 （「あまりにも異なる」が実際に何であるかはわかりませんでした。昨日新しいサーバーでこの問題が発生したため、1分で解決できることはわかっています。）

Kerberos認証が失敗した場合、SSMSはおそらく接続を維持しますが、NTLM認証の使用にサイレントにフォールバックします。

接続設定と文字列を微調整することでKerberosを強制的に実行できるため、Kerberos認証の場合、接続はハードに失敗しますが、Kerberosで接続しているかどうかを確認する簡単な方法があります。 Kerberos認証を使用して接続していることを確認するには、通常どおりSSMS経由で接続し、SSMSクエリウィンドウでこれを実行します。

master.sys.dm_exec_connectionsからauth_schemeを選択します。ここでsession_id = @@ spid

「KERBEROS」が表示されます。そうでない場合は、おそらく「NTLM」が表示され、何かが間違っていることがわかります。

1
darin strait