IIS AppPoolIdentityおよびファイルシステムの書き込みアクセス許可

これは、私が調査してどこにも行き着かないIIS 7.5とASP.NETの問題です。どんな助けでも大歓迎です。

私の質問は、IIS 7.5でASP.NETを使用して、IISまたはオペレーティングシステム、あるいはその両方で、C:\dump完全な信頼の下で実行している場合と同様に、Webアプリケーションがフォルダーに書き込むことをどのように許可するのですか？アプリケーションプールユーザーの書き込みアクセスを明示的に追加する必要がないのはApplicationPoolIdentityなぜですか（この場合）。

これだけ私は知っています：

• IIS 7.5では、アプリケーションプールのデフォルトのIDはApplicationPoolIdentityです。
• ApplicationPoolIdentity アプリケーションプールの作成時に作成される「IIS APPPOOL \ AppPoolName」というWindowsユーザーアカウントを表します。AppPoolNameはアプリケーションプールの名前です。
• 「IIS APPPOOL \ AppPoolName」ユーザーは、デフォルトでIIS_IUSRSグループのメンバーです。
• あなたは完全信頼で実行されている場合は、あなたのWebアプリケーションは、ファイルシステムの多くの地域（除くフォルダが好きに書き込むことができるC:\Users、C:\Windowsなど）。たとえば、アプリケーションには、などの一部のフォルダへの書き込みアクセス権がありますC:\dump。
• デフォルトでは、IIS_IUSRSグループには読み取りまたは書き込みアクセス権が与えられていませんC:\dump（少なくとも、Windowsエクスプローラの[セキュリティ]タブから表示されるアクセス権は与えられていません）。
• への書き込みアクセスを拒否するとIIS_IUSRS、（期待どおりに）フォルダに書き込もうとするとSecurityExceptionが発生します。

それで、それらすべてを考慮に入れて、「IIS APPPOOL \ AppPoolName」ユーザーに書き込みアクセス権をどのように付与しますか？w3wp.exeプロセスはこのユーザーとして実行されるので、明示的にアクセスできないように見えるフォルダーにこのユーザーが書き込むことを許可するものは何ですか？

完全信頼で実行している場合、書き込み先のすべてのフォルダへのアクセス権をユーザーに付与するのは面倒なので、これはおそらく便宜上行われたと理解しています。このアクセスを制限したい場合は、常に中程度の信頼の下でアプリケーションを実行できます。明示的なファイルシステムアクセスが許可されていないように見えても、オペレーティングシステムやIISがこれらの書き込みを許可する方法について知りたいです。

にApplicationPoolIdentityは、Usersグループおよびグループのメンバーシップが割り当てられIIS_IUSRSます。一見すると、これはやや心配に見えるかもしれませんが、UsersグループにはNTFS権限がいくらか制限されています。

たとえば、フォルダ内にC:\Windowsフォルダを作成しようとすると、作成できないことがわかります。ApplicationPoolIdentityまだWindowsのシステムフォルダからファイルを読み取ることができる必要がある（そうでない場合はどのように他のワーカープロセスが動的に不可欠なDLLのをロードすることができるだろう）。

c:\dumpフォルダーへの書き込みが可能であるという観察結果について。[セキュリティの詳細設定]で権限を確認すると、次のように表示されます。

から継承されている特別な権限を参照してくださいc:\。

これが、サイトがそのフォルダーに対して読み書きApplicationPoolIdentityできる理由です。その権利はドライブから継承されています。c:\

数百のサイトがあり、それぞれに独自のアプリケーションプールとアプリケーションプールIDがある共有環境では、サイトフォルダーを、Usersグループが削除され、アクセス許可がAdministratorsとSYSTEMアカウントにはアクセス権があります（継承あり）。

次に、それぞれがそのIIS AppPool\[name]サイトのルートフォルダーに必要とする必要なアクセス許可を個別に割り当てます。

また、潜在的に機密性の高いファイルやデータを格納するフォルダを作成する場合は、Usersグループが削除されていることを確認する必要があります。また、インストールするアプリケーションが機密データをc:\program files\[app name]フォルダーに格納しないこと、およびユーザープロファイルフォルダーを代わりに使用することも確認する必要があります。

つまり、一見すると、にApplicationPoolIdentityは必要以上の権限があるように見えますが、実際には、グループメンバーシップが要求する以上の権限はありません。

アンApplicationPoolIdentityのグループメンバーシップは、SysInternalsのは、使用して調べることができExplorerツールを処理します。関心のあるアプリケーションプールIDで実行されているワーカープロセスを見つけます（User Name表示する列のリストに列を追加する必要があります：

たとえば900300、アプリケーションプールID がのプールがここにありIIS APPPOOL\900300ます。プロセスのプロパティを右クリックし、表示される[セキュリティ]タブを選択します。

ご覧のとおりIIS APPPOOL\900300、Usersグループのメンバーです。

1. フォルダを右クリックします。

2. プロパティをクリックします

3. [セキュリティ]タブをクリックします。次のようなものが表示されます。

4. 上の画面で「編集...」ボタンをクリックします。次のようなものが表示されます。

5. 上の画面で「追加...」ボタンをクリックします。次のようなものが表示されます。

6. 上の画面の[場所...]ボタンをクリックします。このようなものが表示されます。次に、このツリー構造の一番上に移動してコンピューター名を選択し、[OK]をクリックします。

7. 「iis apppool \ your_apppool_name」と入力して、「名前の確認」ボタンをクリックします。アプリプールが存在する場合は、テキストボックスにアプリプール名と下線が表示されます。OKボタンをクリックします。

8. アカウントに付与する必要があるアクセスをチェック/チェック解除します

9. [適用]ボタンをクリックして、[OK]をクリックします。

IIの各アプリケーションプールは、デフォルトでc：\ usersの下に完全な読み取り/書き込み権限を持つ独自の安全なユーザーフォルダーを作成します。ユーザーフォルダーを開き、そこにあるアプリケーションプールフォルダーを確認して右クリックし、割り当てられたアプリケーションプールの仮想アカウントに対する権限を確認します。ルートとサブフォルダーに読み取り/書き込みアクセス権が割り当てられたアプリケーションプールアカウントが既に追加されているはずです。

そのため、このタイプのファイルストレージアクセスは自動的に行われ、何も変更せずにアプリプールのユーザーアカウントフォルダーに好きなものを書き込むことができるはずです。これが、各アプリケーションプールの仮想ユーザーアカウントが作成された理由です。

IISのWebサイトへのアクセスの問題を修正するためにこれを試しました。これは、イベントログ→Windows→アプリケーションで次のように表示されます。

ログ名：アプリケーション
ソース：ASP.NET 4.0.30319.0
日付：1/5/2012 4:12:33 PM
イベントID：1314
タスクカテゴリ：Webイベント
レベル：情報
キーワード：クラシック
ユーザー：なし
コンピューター：SALTIIS01

説明：
イベントコード：4008 
イベントメッセージ：リクエストのファイル認証に失敗しました。 
イベント時間：1/5/2012 4:12:33 PM 
イベント時間（UTC）：1/6/2012 12:12:33 AM 
イベントID：349fcb2ec3c24b16a862f6eb9b23dd6c 
イベントシーケンス：7 
イベント発生：3 
イベント詳細コード：0 

アプリケーション情報： 
    アプリケーションドメイン：/ LM / W3SVC / 2 / ROOT / Application / SNCDW-19-129702818025409890 
    信頼レベル：完全 
    アプリケーション仮想パス：/ Application / SNCDW 
    アプリケーションパス：D：\ Sites \ WCF \ Application \ SNCDW \ 
    マシン名：SALTIIS01 

プロセス情報： 
    プロセスID：1896 
    プロセス名：w3wp.exe 
    アカウント名：iisservice 

要請情報： 
    リクエストURL：http：//webservicestest/Application/SNCDW/PC.svc 
    リクエストパス：/Application/SNCDW/PC.svc 
    ユーザーホストアドレス：10.60.16.79 
    ユーザー：js3228 
    認証済み：True 
    認証タイプ：交渉 
    スレッドアカウント名：iisservice 

結局、私はWindows Everyoneグループにそのフォルダーへの読み取りアクセスを与えて、フォルダーを正しく機能させる必要がありました。