2009-07-13 30 views
0

IIS6のインスタンスでは、Windows認証とImpersonate = trueのイントラネットWebサイトが実行され、クライアントブラウザから渡されたNT資格情報が使用されます。 AppPoolはネットワークサービスユーザー:serviceAcctXとして実行されるように設定されています。まれに偽装を元に戻すことができます(クライアントユーザーがアクセスできないリソースを読み書きする)IISが仮想ディレクトリをファイル共有に移動すると、ログオンユーザーの偽装が壊れる

ソース仮想ディレクトリのローカルドライブ上にあります。ログインしたユーザーは認証され、ページのコンテンツは承認設定に基づいてカスタマイズされます。

私たちのインフラストラクチャチームは、仮想ディレクトリソースをリモートサーバー上のファイル共有に移動しようとしています。特定のファイル共有パスに対して完全な信頼を追加して、.Netセキュリティポリシーを変更することで、既に問題を解決しています。私たちは、AppPoolが実行しているものと同じserviceAcctXにConnect Asプロパティを設定しました。

サイトが正常に開始されます。ただし、クライアントユーザーは偽装されません。以前のようにクライアントのNT資格情報ではなく、デフォルトのserviceAcctX資格情報を使用して要求が処理されます。

クライアントの偽装を以前と同じように動作させる方法はありますか?ファイル共有に仮想ディレクトリがありますか?どんな指針も大変ありがとうございます。

答えて

1

私はNot A Good Ideaのカテゴリに入れました。

多くの潜在的な問題が発生し、多くの複雑な依存性が導入されています。

代わりに、私はもう少し "オフライン"なものを探しています。ファイル複製を使用して、Webサーバーとリモートサーバーの間でファイルを同期させます。

少し複雑ですが、アプリケーションの存続可能性が向上します。つまり、リモートサーバーが再起動したり、ダウンしたり、2つの間にネットワークの問題がある場合、アプリはまだ機能しています。さらに、ファイルをリモートサーバーに置くこともできます。

0

ユーザーのトークンを渡すために、WebサーバーのActive Directoryで「このコンピュータを委任する」チェックボックスをオンにする必要があります。

+0

これが適切な解決策であるかどうかはわかりません。委任はここでは問題ではありません。問題は以前のようにログオンしたユーザーの資格情報ではなく、serviceAcctX資格情報を使用してワーカープロセスが生成されることです。 – Tion

関連する問題