web-dev-qa-db-ja.com

IIS / ASP.NETのすべてのユーザーアカウントは何ですか?またそれの違いは何ですか?

ASP.NET 4.0がインストールされているWindows Server 2008では、関連するユーザーアカウントは多数ありますが、どれがどのユーザーアカウントでどのように異なるのか、そしてどれが本当に自分のアプリケーションが実行されているのかわかりません。これがリストです:

  • IIS_IUSRS
  • IUSR
  • DefaultAppPool
  • ASP.NET v4.0
  • NETWORK_SERVICE
  • ローカルサービス.

何が何?

261
Vilx-

これは非常に良い質問です。残念ながら、多くの開発者はWeb開発者であることとIISをセットアップすることに関して、IIS/ASP.NETセキュリティについて十分な質問をしていません。だからここに行きます....

リストされたアイデンティティをカバーするために:

IIS_IUSRS:

これは古いIIS6のIIS_WPGグループに似ています。これは、このグループの任意のメンバーがアプリケーションプールIDとして機能できるようにセキュリティが設定された組み込みグループです。

IUSR:

このアカウントは、IIS 5およびIIS 6 Webサイトのデフォルトの匿名ユーザー(サイトのプロパティの[ディレクトリセキュリティ]タブで構成されたもの)であった古いIUSR_<MACHINE_NAME>ローカルアカウントに似ています。

IIS_IUSRSおよびIUSRについて詳しくは、以下を参照してください。

IIS 7の組み込みのユーザーアカウントとグループアカウントについて

DefaultAppPool:

アプリケーションプールがアプリケーションプールID機能を使用して実行するように構成されている場合は、プールIDとして使用するために、IIS AppPool\<pool name>という「合成」アカウントがその場で作成されます。この場合、プールの有効期間中に作成されたIIS AppPool\DefaultAppPoolという合成アカウントがあります。プールを削除すると、このアカウントはもう存在しなくなります。ファイルやフォルダにアクセス許可を適用するときは、IIS AppPool\<pool name>を使用してこれらを追加する必要があります。また、コンピュータのユーザーマネージャにこれらのプールアカウントは表示されません。詳細については、以下を参照してください。

アプリケーションプールID

ASP.NET v4.0: -

これは、ASP.NET v4.0アプリケーションプールのアプリケーションプールIDになります。上記のDefaultAppPoolを参照してください。

NETWORK SERVICE: -

NETWORK SERVICEアカウントは、Windows 2003で導入された組み込みIDです。NETWORK SERVICEは、アプリケーションプールやWebサイトを実行できる特権の低いアカウントです。 Windows 2003プールで実行されているWebサイトは、そのサイトの匿名アカウント(IUSR_、または匿名IDとして構成したもの)を偽装することができます。

Windows 2008より前のASP.NETでは、アプリケーションプールアカウント(通常はNETWORK SERVICE)の下でASP.NETに要求を実行させることができました。あるいは、ローカルで<identity impersonate="true" />ファイルのweb.config設定を介してサイトの匿名アカウントを偽装するようにASP.NETを設定することもできます(その設定がロックされている場合は、machine.configファイルの管理者が行う必要があります)。

<identity impersonate="true">の設定は、共有アプリケーションプールが使用される共有ホスティング環境では一般的です(偽装アカウントの巻き戻しを防ぐための部分的な信頼設定と組み合わせて)。

IIS7.x/ASP.NETでは、偽装制御はサイトの認証設定機能を介して設定されるようになりました。そのため、プールID、IUSR、または特定のカスタム匿名アカウントとして実行するように構成できます。

LOCAL SERVICE:

LOCAL SERVICEアカウントは、サービスコントロールマネージャによって使用される組み込みアカウントです。ローカルコンピュータに対する最小限の特権セットがあります。使用範囲はかなり限られています。

LocalService Account

LOCAL SYSTEM:

あなたはこれについて尋ねませんでした、しかし私は完全性のために加えています。これはローカルのビルトインアカウントです。それはかなり広範な特権と信頼を持っています。このIDで実行するようにWebサイトまたはアプリケーションプールを構成しないでください。

ローカルシステムアカウント

実際には:

実際には、Webサイトを保護するための推奨されるアプローチ(サイトが独自のアプリケーションプールを取得する場合 - これはIIS 7のMMCの新しいサイトのデフォルトです)はApplication Pool Identityの下で実行することです。これは、アプリケーションプールの[詳細設定]でサイトのIDをApplication Pool Identityに設定することを意味します。

enter image description here

Webサイトで、認証機能を設定します。

enter image description here

匿名認証エントリを右クリックして編集します。

enter image description here

"アプリケーションプールID"が選択されていることを確認します。

enter image description here

ファイルとフォルダのアクセス許可を適用するようになったら、必要な権限を何でもアプリケーションプールIDに付与します。たとえば、ASP.NET v4.0プールのアクセス許可に対してアプリケーションプールIDを付与している場合は、エクスプローラで次のいずれかを実行できます。

enter image description here

[名前の確認]ボタンをクリックしてください。

enter image description here

あるいはICACLS.EXEユーティリティを使ってこれを行うことができます。

icacls c:\ wwwroot\mysite/grant "IIS AppPool\ASP.NET v4.0" :( CI)(OI)(M)

...または...サイトのアプリケーションプールの名前がBobsCatPicBlogthenの場合

icacls c:\ wwwroot\mysite/grant "IIS AppPool\BobsCatPicBlog" :( CI)(OI)(M)

これが問題解決に役立つことを願っています。

更新:

私は2009年からこの優れた回答にぶつかりました。これには読む価値のある有用な情報がたくさん含まれています。

'Local System'アカウントと 'Network Service'アカウントの違いは?

406
Kev