SQL一括挿入の偽装の問題
Microsoft SQL Server 2012を実行していますSP。SQL Serverサービスは、単純なWindowsドメインユーザーとして実行されています（特別なもの、管理者権限なしなど）
Windows認証を使用しているときに、データファイルがネットワーク共有上にあるときに一括挿入を使用すると問題が発生します。既知のことは、SQL Serverサービスアカウントがネットワークリソースにアクセスできることです。これは、SQLアカウントでSQL Serverにログインし、一括挿入を実行することで表示されます。そこにファイルをputしたことからわかるように、共有上のファイルに対する権利も持っています。
ここで、Windows認証を使用してSQL Serverに接続し、一括挿入を実行すると、次のエラーが発生します（私の強調）。
メッセージ4861、レベル16、状態1、行2ファイル "\\ [server]\[share]\[filename]"を開けなかったため、一括読み込みできません。オペレーティングシステムエラーコード5（アクセスが拒否されました）。
私はこの切り取りを BULK INSERT（Transact-SQL）\ Security Account Delegation（Impersonation） で見つけました。
このエラー[4861]を解決するには、SQL Server認証を使用して、SQL Serverプロセスアカウントのセキュリティプロファイルを使用するSQL Serverログインを指定するか、セキュリティアカウントの委任を有効にするようにWindowsを構成します。ユーザーアカウントを委任に対して信頼できるようにする方法については、Windowsヘルプを参照してください。
最後に、多くの検索を行った後、このTechNetの記事 委任に対して信頼されるようにサーバーを構成する方法 を見つけ、制約のない委任を試み、SQLサーバーを再起動しましたが、それでも機能しません。
一体何が欠けているの???
OK、これが私の特定の問題に対する答えです。上記のコメントは非常に役に立ち、SPNを手動で追加するなど、いくつかの良い提案がありましたが、最後の部分が1つ欠けていました。ご存知のように、月の途中でワックスがかかっているときのみ、月の第3木曜日に嵐が発生します...
この投稿から数日後、基本的に同じ質問を Microsoft SQLフォーラム に投稿して、新鮮な展望を得ました。要するに、ネットワーク管理者にadsiedit.mscを実行させ、サービスのドメインアカウントユーザーを編集してもらう必要がありました。 userAccountControl属性は、更新する必要があったビットマップフィールドを表す数値です。私は単一の既存の数値、0x10200（NORMAL_ACCOUNT | DONT_EXPIRE_PASSWORD）およびOR in 0x80000（TRUSTED_FOR_DELEGATION）およびOR in 0x1000000（TRUSTED_TO_AUTH_FOR_DELEGATION）合計0x1090200！
さて、そのユーザーフレンドリーではありません！委任用のGUIでアカウントをセットアップしたときに、これらのビットも設定されなかったのはなぜなのか、正直なところわかりません。
信頼できる接続（Windows認証）で一括挿入を正しく実行し、3つのうち2つのSQLサーバーで正しく偽装しました。なぜそれが1つではないのかはわかりませんが、それは別の日です...