「アプリケーションプールID」は、アプリケーションプールに対してどのような役割を果たしますか？

Question

IIS 7.5セキュリティについて話すとき、私の知る限り：

アプリケーションプールIDが決定whom私のWebアプリケーションは次のように実行されます。

認証方法が決定whomクライアントが認証されるときのように。

私はこのように構成された仮想フォルダを持っています：

すべてのクライアントが[〜＃〜] iusr [〜＃〜]として認証されることを期待して、匿名認証を使用します。
IUSRにフォルダーの完全な制御権を与えます。
アプリプールIDがXXXアカウントとして設定されていますが、このアカウントにはフォルダーへのアクセス許可がありません。（私は意図的にこれを設定しました）

しかし、そのフォルダー内のファイルを参照できないことがわかりました。 XXXアカウントにそのフォルダーにアクセスするためのアクセス許可を与えると、うまくいきます。

では、アプリプールIDは匿名認証でどのような役割を果たすのでしょうか。フォルダーにアクセスするためのアクセス許可をアプリプールIDアカウントに与えなければならないのはまったく予想外です。匿名認証で十分だと思いましたか？

ありがとう。

TristanK · Accepted Answer

ここには多くのオーバーロードされた用語があり、IIS 7と7.5の間の変更点があります。

アプリプールIDとアプリプールアカウント

アプリケーションプールID（小文字I、別名アプリケーションプールアカウント）から始めましょう。

アプリケーションプールアカウントは、アプリプールをブートするために使用されるアカウントです。アプリプールが他のユーザーになりすましていないときに想定するID。

したがって、アプリプールに与えるIDは、コンテンツフォルダー内のファイルを読み取ることができる必要があります：特に{ただし、これに限定されません}任意のweb.configファイル（IIS構成の一部を形成し、アプリケーションプールの動作を制御しますやっている）。

フォルダーにアクセスできない場合は、そこに重要な（ゲームを変える）web.configファイルがあると想定し、エラーを表示します。したがって、アプリプールアカウントには、すべてのコンテンツフォルダーへのReadアクセスが必要です。

ApplicationPoolIdentity

アプリプールアカウント（アプリプールのID）とアプリプールIDを区別する理由使用される特別な大文字ApplicationPoolIdentityは新しいアカウントtype-管理されたサービスアカウント-であるためIIS 7.5/Windows 2008 R2でデフォルトになり、Windows 2008 SP2からも使用できます（ただしデフォルトではありません）。

IIS.NetのアプリケーションプールID を参照してください。

GUIを使用してR2でWebサイトを作成する場合：

そのWebサイトをホストするためのアプリプールが作成されます。
アカウントの種類は、Network Service（2008のデフォルト）、Local Service、Local Systemではなく、ApplicationPoolIdentityになります。

2008 RTMでは、デフォルトのアプリプールアカウントはネットワークサービスplusで、一意のアプリプールID /一意名でした。新しいR2/SP2 AppPoolIdentityaccount typeはNetwork-Service-likeアカウントです（つまり、オフボックスに接続するときのコンピューターです））、同じボックス内の別のアプリプールの偽装を防止します。

元の質問に戻ります：

アプリプールアカウントは、whoアプリを他人になりすましていないとき
認証方法は、クライアントを認証する方法を記述します（それらを偽装するための命令）
匿名ユーザーアカウントは、認証されていないリクエストに対してユーザーを偽装するときに実行するユーザーを定義します-IUSRはそのようなユーザーです。

ちなみに、IIS 7.5では、匿名ユーザーアカウントをアプリケーションプールID（匿名認証方法のプロパティ）に設定できます。これにより、コンテンツの分離と保護がより簡単になります特定のウェブサイト。

名前の形式については、IIS AppPool\YourSiteNameを使用してアクセス許可を設定します（ this post も参照）

Stokely · Answer

ASP.NETでよく混乱する2つのことがわかります。

「ユーザーID」-ユーザーアカウントの認証は、IIsとASP.NETの両方で実際に実行されるアカウントまたはIDとは関係ありません。匿名認証により、すべてのユーザーがクライアントブラウザにユーザー名とパスワードのチャレンジを提供することなく、パブリックコンテンツにアクセスできます。 IISでデフォルトで認証される匿名IUSRアカウントは、パブリックWebサイトコンテンツへのアクセスを適用するだけです。基盤となるIIまたはASP.NETサービスで使用されるプロセスやリソースには影響しません。
「アプリケーションID」-これは、実際に背後で実行されるサーバー上の実際の「WindowsIdentity」アカウントですIISおよびASP.NET。IISによってプールに割り当てられ、指定されたアプリケーションプールIDアカウントです。 ASP.NET。ASP.NETプロセスは、デフォルトでこのアプリケーションプールIDアカウント（IIsバージョン7.5以降では仮想アカウントと呼ばれます）で実行されます。

説明：まず、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を実行します。

IIsがこのセットアップで起動し、ユーザーがアクセスすると、デフォルトでは、Webページやその他の基本リソースへのアクセスを決定する匿名のIUSRアカウントが実際に舞台裏で認証されます。ただし、そのアカウントはASP.NETに渡されません。また、アプリケーションプールID IISの実行、および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の推奨事項によるものです）。

幸運を！

Steve Mayne · Answer

2つの認証コンテキストがあります。（Webリクエストを処理する）Webサーバープロセスは、App Pool Identityユーザーとして実行されます。仮想ホストにリクエストが送られると、アプリケーションプールは特定のサイトの「匿名認証資格情報」にリストされているユーザーになりすまします-デフォルトではIUSR。

ウェブサイト内から実行されるスクリプトはすべてIUSRとして実行されますが、ロギングおよびその他の特定の機能はアプリプールユーザーとして実行されます（デフォルトではネットワークサービス-特別な仮想アプリプールユーザーを使用するように最近変更されています）。制御がスクリプトに渡される前に要求スタックで特定のチェックが行われるため、アプリケーションプールID（ネットワークサービス）はディレクトリ内のファイルを一覧表示できる必要があります。

プールごとに1つのサイトを実行し、アプリプールIDをWebサイトの匿名ユーザーと同じユーザーとして実行するように設定することをお勧めします。匿名ユーザーコンテキスト（IUSR）から抜け出し、特権をアプリプールID自体の特権に昇格することができます。