IIS 7.5のセキュリティについて話すとき、知る限り：
App Pool Identityは、Webアプリケーションの実行者を決定します。
認証方法は、クライアントの認証者を決定します。
次のように構成された仮想フォルダーがあります。
しかし、そのフォルダー内のファイルを参照できないことがわかりました。XXXアカウントにそのフォルダーへのアクセス許可を与えると、うまくいきます。
では、匿名認証でアプリプールIDはどのような役割を果たしますか？フォルダーにアクセスするために、アプリケーションプールIDアカウントにアクセス許可を与える必要があるのはまったく予想外です。匿名認証で十分だと思いましたか？
ありがとう。
回答:
ここで多くのオーバーロードされた用語、およびIIS 7と7.5の間の変更。
アプリケーションプールID（小文字のI、別名アプリケーションプールアカウント）から始めましょう。
言い方をすれば、アプリケーションプールアカウントは、アプリケーションプールを起動するために使用されるアカウントであり、他の人になりすましていないときにアプリケーションプールが想定するIDです。
したがって、アプリケーションプールにどのようなIDを与えても、コンテンツフォルダー内のファイルを読み取ることができる必要があります。特に、IIS構成の一部を形成し、何を制御するweb.configファイル（特に限定されません）アプリプールが行われます）。
フォルダーにアクセスできない場合、重要な（ゲームを変更する）web.configファイルが存在する可能性があると想定し、エラーを表示します。そのため、アプリケーションプールアカウントには、すべてのコンテンツフォルダーへの読み取りアクセスが必要です。
アプリプールアカウント（アプリプールのID）とアプリプールIDを区別する理由 特別な大文字を使用したApplicationPoolIdentityは新しいアカウントタイプ（管理されたサービスアカウント）であり、IIS 7.5 / Windows 2008 R2で導入およびデフォルトになり、Windows 2008 SP2からも利用可能になりました（ただし、デフォルトではありません）。
IIS.NetのアプリケーションプールIDを参照してください
GUIを使用してR2の下にWebサイトを作成する場合：
2008 RTMでは、デフォルトのアプリケーションプールアカウントはネットワークサービスと一意のアプリプールID /一意名でした。新しいR2 / SP2 AppPoolIdentity アカウントタイプはネットワークサービスのようなアカウント（つまり、オフボックスに接続するときのコンピューター）ですが、同じボックス内の別のアプリケーションプールのなりすましを防ぎます。
アプリプールアカウントは、他人になりすましていないときにアプリを実行するユーザーを定義します
認証方法は、クライアントを偽装するためにクライアントを認証する方法を記述します
匿名ユーザーアカウントのあなたが認証されていない要求のためのユーザーを偽装する場合として実行するつもり定義- IUSRなユーザーです。
ちなみに、IIS 7.5では、匿名ユーザーアカウントをアプリケーションプールID（匿名認証方法のプロパティ）に設定できます。これにより、特定のWebサイトのコンテンツを簡単に分離して保護できます。
名前の形式にIIS AppPool \ YourSiteNameを使用してアクセス許可を設定します。（この投稿も参照）
ASP.NETでよく混同される2つのことがわかります。
説明：まず、ASP.NETの「認証」は、通常、web.configでセットアップされるイベントであり、IIsによってプレーンHttpContextオブジェクトとしてユーザートークンとしてASP.NETに渡される特定のユーザーアカウントにログインします...つまり、現在のセッションまたは現在のユーザーのコンテキスト。実際には、ASP.NETプロセスを実行しているWindowsIdentityを変更するのではなく、ユーザーIDトークンを渡すだけです。HttpContextを使用すると、コードはそのIDまたは名前を使用して、Webサイトのさまざまなセクションに対するデータベース権限を保存できます。ただし、IISでASP.NETを実行する実際のアプリケーション「プロセス」アカウントのIDに影響を与えたり変更したりしないため、ASP.NETによるファイルアクセスには影響しません。
これは、IISから渡されたトークンを偽装し、そのアカウントIDで実行するようにASP.NETに指示する「偽装」を行うまでは発生しません。web.configで偽装を設定できます。ASP.NETで偽装を有効にすると、WindowsIdentityはワーカープロセスでIISからASP.NETに渡される認証済みアカウントに変更され、ユーザーアカウントに割り当てる権利に基づいてファイルにアクセスできます。それが一時的に発生し、ASP.NETが現在のIIsバージョンにある既定のプロセスIDに戻り、特定のアプリケーションプールに割り当てられたアプリケーションプールIDアカウントに戻ることに注意することが重要です。
IIsがASP.NETで明示的な認証を設定せずにプレーンな匿名ユーザーアカウントを使用する場合、IIsはデフォルトでWebサイトに割り当てられたアプリケーションプールのアプリケーションプールIDアカウントを起動し、ASP.NETとそれを実行するワーカープロセスに渡します。そのアプリケーションプールIDアカウントは、IISに対するすべての要求を処理し、そのサイトに対してASP.NETを実行します。
このセットアップでIIが起動し、ユーザーがアクセスすると、Webページやその他の基本リソースへのアクセスを決定する匿名IUSRアカウントがデフォルトで実際に舞台裏で認証されます。ただし、そのアカウントはASP.NETに渡されません。また、IISが実行されているアプリケーションプールIDおよびASP.NETが実行されているアプリケーションプールには影響しません。
たとえば、web.configでImpersonateを「true」に設定し、IISでパブリックアクセスにデフォルトの匿名IUSRアカウントを使用し、かつ（Windowsを使用する代わりにweb.configでanonymousAuthenticationプロパティを明示的にtrueに設定した場合またはその他のログインアカウント）、IIsはアプリケーションプールIDを破棄し、IIsとASP.NETは両方とも、匿名IUSR認証および偽装アカウントとしてアプリケーションプロセスを実行します。
これを行うと、ASP.NETとそのプロセスはIUSRアカウントで実行されます。つまり、ASP.NETのアプリケーションプロセスはWindowsIdentityアカウントをIUSRアカウントとして実行します。これで、その匿名IUSRアカウントと、そのアカウントにアクセスさせたいフォルダーに読み取り/書き込みアクセスを適用できます。（注：ただし、既定のプロセスアカウント、プールのアプリケーションプールアカウント、およびそれらのフォルダーへの権限も必ず追加してください。これは、Microsoftの推奨に従っています）
幸運を！
プレイには2つの認証コンテキストがあります。Webサーバープロセス（Web要求を処理する）は、アプリケーションプールIDユーザーとして実行されます。仮想ホストへの要求が着信すると、アプリケーションプールは、特定のサイトの「匿名認証資格情報」にリストされているユーザーになりすます-デフォルトではIUSR。
Webサイト内から実行されるスクリプトはすべてIUSRとして実行されますが、ログおよび特定のその他の機能はアプリプールユーザーとして実行されます（デフォルトではネットワークサービス-これは最近特別な仮想アプリプールユーザーを使用するように変更されています）。アプリケーションプールID（ネットワークサービス）は、制御がスクリプトに渡される前に特定のチェックがリクエストスタックで行われるため、ディレクトリ内のファイルを一覧表示できる必要があります。
プールごとに1つのサイトを実行し、Webサイトの匿名ユーザーと同じユーザーとして実行するようにアプリケーションプールIDを設定することをお勧めします。匿名ユーザーコンテキスト（IUSR）から抜け出し、特権をアプリケーションプールID自体の特権に昇格させることができます。