なりすましと委任

Question

次のように、UNC共有上のファイルにアクセスするために偽装を使用しています。

  var ctx = ((WindowsIdentity)HttpContext.Current.User.Identity).Impersonate();
  string level = WindowsIdentity.GetCurrent().ImpersonationLevel);

IIS6を使用する2つのWindows 2003サーバーで、1つのサーバーで委任と他のサーバーで偽装の偽装レベルが異なります。

これにより、サーバーのUNC共有に「偽装」レベルでアクセスできないという問題が発生します。

この違いの原因は何ですか？ machine.configおよびIIS設定でアプリプール、サイト、および仮想ディレクトリを検索しましたが、この問題の原因を見つけることができません。

Answer 1

一方のコンピューターはActive Directoryによる委任に対して信頼されているようですが、もう一方は信頼されていないようです。アプリプールIDがネットワークサービスの場合、コンピューターアカウントが「委任に対して信頼されている」とマークされていることを確認します。 ADで。

AD管理者に複製を強制してから、ワークステーションにログアウト/ログインして、Kerberosチケットキャッシュを更新する必要がある場合があります。

Answer 2

localhostをウェブサーバーとして使用してテストし、その動作中にデプロイしたときにエラーが発生した場合、このブログ投稿

Answer 3

Impersonate（）を行ったアプリケーションの1つで、アプリケーションプールの所有者のローカルセキュリティポリシーを変更し、そのアカウントを次のポリシー/グループに追加する必要があることがわかりました。

1. オペレーティングシステム権限の一部として機能。
2. 認証後にクライアントを偽装します。

サーバーで、[開始]＆gt;を実行しますすべてのプログラム＆gt;管理ツール＆gt;次に、ローカルセキュリティポリシーに移動して、ローカルセキュリティポリシー＆gt;ユーザー権利の割り当てを行い、上記の2つのポリシーを探します。