リモート コンピューターで exe を実行したい。私は次のように設定しました：
トラブルシューティング：
すべてを手動で実行できる理由は誰にもわかりますが、SQLサーバーエージェントジョブを設定して、リモートコンプでexeを実行するだけでは機能しませんか??
私は実際に、無効であるほど攻撃的ではない満足のいくハックを見つけました... SQLエージェントによってトリガーされるバットを作成しました。Bat ファイルは目的の exe を起動します。
なぜこれで同じアクセスの問題が発生しないのかはわかりませんが、そうではないことを嬉しく思います:)
バットファイルの内容
start \\xxxxxx\xxxxxx\xxxx.exe
これは予期される動作です。偽装されたコンテキストでリモートを認証すると、Kerberos Constrained Delegation ルールが適用されます (別名「ダブル ホップ」)。Windows 認証を使用して SQL Server に接続すると、偽装されたコンテキストが実行されます。SQL 認証を使用して接続すると、リモート アクセスはその SQL ログイン用に構成されたプロキシ ログインを使用します。
すべての「成功」ケースはすべて、ダブルホップがないか、使用できるプロキシ ユーザーが存在する側にあります。失敗したケースはすべて、Windows 認証ログインによる「ダブルホップ」です (したがって、プロキシ ユーザーではなく偽装を使用します)。
説明したように、この問題は簡単に修正できます。"\host\c$\path\program.exe" を SQL インスタンス ホストにローカルにコピーし、ローカルで実行します ("c:\path\program.exe")。これには、ダブルホップを回避すること以外にも、他にも理由があります。しかし、プログラム自体がリモート アクセスを必要とする可能性が非常に高く、それによって制約付き委任がトリガーされます。
したがって、適切な修正は、アクセスしたい特定のサービスに対して制約付き委任を設定する ことです。これは本当に苦痛ですが、前進する唯一の方法です。ネットワーク管理者とドメイン管理者にその方法を話してください。彼らは関与する必要があり (彼らだけが持つ特定の権限が必要です)、彼らはその方法を知っています。Windows 2012 では、セットアップがはるかに簡単です。Windows Server 2012 が Kerberos Constrained Delegation の痛みを緩和する方法、パート 1を参照してください。