この記事では、インターネット インフォメーション サービス (IIS) の ID に関する背景情報を提供します。
元の製品バージョン: インターネット インフォメーション サービス
元の KB 番号: 4466942
アプリケーション プール識別子
アプリケーション プール ID を理解するには、ID とは何かを理解する必要があります。 簡単に言うと、ID は Windows アカウントです。 Windows で実行されるすべてのプロセスは、ID で実行されます。 アプリケーションは、Windows ID を使用してワーカー プロセスによって実行されます。 使用される Windows ID は、アプリケーション プール ID に依存します。次のいずれかのアカウントを使用できます。
- ローカル システム: 高い特権を持ち、ネットワーク リソースにもアクセスできる信頼されたアカウント。
- Network Service: 標準の最低特権サービスを実行するために使用される制限または限定されたサービスアカウント。 このアカウントの権限は、ローカル システム アカウントよりも少なくなります。 このアカウントは、ネットワーク リソースにアクセスできます。
- ローカル サービス: ネットワーク サービスに似ていて、標準の最小特権サービスを実行することを目的とした制限付きまたは制限付きサービス アカウント。 このアカウントには、ネットワーク リソースへのアクセス権がありません。
- ApplicationPoolIdentity: 新しいアプリケーション プールが作成されると、IIS は新しいアプリケーション プールの名前を持ち、このアカウントでアプリケーション プールワーカー プロセスを実行する仮想アカウントを作成します。 これは、最小限の特権を持つアカウントでもあります。
- カスタム アカウント: これらの組み込みアカウントに加えて、ユーザー名とパスワードを指定してカスタム アカウントを使用することもできます。
アプリケーション プール ID の違い
シナリオ 1: イベント ログへのアクセス
このシナリオでは、カスタム イベント ログ (MyWebAppZone) とイベント ログ ソース (MyWebAppZone.com) を実行時に作成する 1 つの Web アプリケーションがあります。 いずれかの ID を使用して実行されるアプリケーションは、既存のイベント ソースを使用してイベント ログに書き込むことができます。 ただし、ローカル システム以外の ID で実行されている場合は、レジストリのアクセス許可が不十分なため、新しいイベント ソースを作成できません。
たとえば、ネットワーク サービスでアプリケーションを実行すると、次のセキュリティ例外が発生します。
ProcMon トレースを同時に実行すると、NT AUTHORITY\NETWORK SERVICE には、次のレジストリ サブキーに対する必要な読み取りおよび書き込みアクセス権がないことがよくあります。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\これは、イベント ログのすべての設定が格納されているレジストリ内の場所です。
シナリオ 2: レジストリ アクセス
ローカル システムとは別に、他のアプリケーション プール ID はレジストリへの書き込みアクセス権を持っていません。 このシナリオでは、Windows が自動的に同期されるインターネット タイム サーバーの名前を変更して表示できる単純な Web アプリケーションを開発しました。 このアプリケーションをローカル サービスで実行すると、例外が発生します。 ProcMon トレースを確認すると、次のレジストリ サブキーで "NT AUTHORITY\LOCAL SERVICE" アプリケーション プール ID に読み取りおよび書き込みアクセス権がないことがわかります。
HKEY_LOCAL_MACHINE** **\SOFTWARE\Microsoft\Windows\CurrentVersion\DateTime\Servers
(シナリオ 1 から) MyWebAppZone イベント ログを確認すると、次のエラー イベントがログに記録されます。
Requested registry access is not allowedエラー メッセージが含まれています。Exception Type: SecurityException Message: Requested registry access is not allowed. Stack Trace at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable) at Identities.ChangeTimeServer.Page_Load(Object sender, EventArgs e) at System.Web.UI.Control.LoadRecursive() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.ProcessRequest() at System.Web.UI.Page.ProcessRequest(HttpContext context) at ASP.changetimeserver_aspx.ProcessRequest(HttpContext context) in c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\fd06117a\f8c94323\App_Web_ysqbhk00.2.cs:line 0 at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)シナリオ 3: Kerberos 認証と負荷分散環境のカスタム アカウント
シナリオ 1 とシナリオ 2 で、組み込みアカウント間の違いをいくつか既に確認しました。 次に、負荷分散された環境で Kerberos 認証を使用する場合に、カスタム アカウントとは何か、組み込みアカウントよりも優れている点について説明します。
この方法を使用すると、特定の Windows ID を使用して実行するように構成されたアプリケーション プールでアプリケーションを実行できます。 2 つのサーバーを含み、Kerberos 認証を使用してクライアントを識別する負荷分散環境でアプリケーションがホストされている次の図を考えてみましょう。
Kerberos 認証を機能させるには、両方のサーバーのマシン アカウントを使用して SPN を設定する必要があります。 アプリケーション プールが組み込みアカウントで実行されている場合は、ネットワーク上のコンピューター資格情報が表示されます。 たとえば、コンピューター名が Server1 の場合、それ自体は "Server1$" として表示されます。 コンピューターがドメインに参加すると、このマシン アカウントが自動的に作成されます。 したがって、N 個のサーバーがある場合は、それぞれのマシン アカウントに対応する N 個の SPN を設定する必要があります。
マシン アカウントへの SPN の登録:
setspn -a HTTP/HOSTNAME MachineAccount$例:
setspn -a HTTP/MyWebAppZone.com Server1$このシナリオでは、同じサービス (この場合は HTTP) の SPN が重複します。この場合、各サーバー アカウントには独自の SPN があります。 この種類の構成は避けてください。
この欠点を克服するには、カスタム Windows (ドメイン) ID でアプリケーションを実行し、SPN をドメイン コントローラー内の特定のドメイン アカウントのみに設定します。
ドメイン アカウントへの SPN の登録:
setspn -a HTTP/HOSTNAME domain\account例:
setspn -a HTTP/MyWebAppZone.com contoso.com\account_alias
wwwroot の既定のアクセス許可とユーザー権限
IIS 7.0 以降のバージョンでは、アプリケーション プール ID を構成し、必要なすべての変更を簡単に行うことができます。 IIS はワーカー プロセスを開始するときに、プロセスが使用するトークンを作成する必要があります。 このトークンが作成されると、IIS は実行時にワーカー プロセス トークンに IIS_IUSRS メンバーシップを自動的に追加します。
アプリケーション プール ID として実行されるアカウントIIS_IUSRS グループの明示的な部分である必要がなくなりました。 Web サイトを作成し、物理的な場所を C:\inetpub\wwwrootにポイントすると、次のユーザーとグループがサイトのアクセス制御リストに自動的に追加されます。
| ユーザー/グループ | 許可されているアクセス許可 |
|---|---|
| クリエイターオーナー | 特別なアクセス許可 |
| SYSTEM | フル コントロール |
| 管理者 | フル コントロール |
| ユーザー | 読み取りと実行、フォルダー内容の一覧表示、読み取り |
| IIS_USRS | 読み取りと実行 |
| TrustedInstaller | フル コントロール |
この機能を無効にして、IIS_IUSRS グループにアカウントを手動で追加する場合は、ApplicationHost.config ファイルで manualGroupMembership の値を true に設定します。 次の例は、既定のアプリケーション プールに対してこれを行う方法を示しています。
<applicationPools>
<add name="DefaultAppPool">
<processModel manualGroupMembership="true" />
</add>
</applicationPools>
構成の分離について
IIS ワーカー プロセスには、 ApplicationHost.config ファイルへの読み取りアクセス権がありません。 そのため、このファイル内の構成セットを読み取る方法を疑問に思うかもしれません。
答えは、IIS 7.0 以降のバージョンの構成分離機能を使用することです。 IIS ワーカー プロセスが構成ファイル階層を読み取るときに ApplicationHost.config を直接読み取る代わりに、Windows プロセス アクティブ化サービス (WAS) は、このファイルのフィルター処理されたコピーを生成します。 各 IIS ワーカー プロセスでは、IIS ワーカー プロセス内で構成が読み取られたときに ApplicationHost.config の代わりにこれらのコピーが使用されます。 これらのファイルは既定で %SystemDrive%\inetpub\Temp\appPools ディレクトリに生成され、 {AppPoolName}.config という名前になります。これらのファイルは、 IIS APPPOOL\AppPoolName アプリケーション プールセキュリティ識別子 (SID) を使用して、対応するアプリケーション プール内の IIS ワーカー プロセスにのみアクセスできるように構成されています。
注意
SID の詳細については、「 セキュリティ識別子」を参照してください。
これは、アプリケーション プール A の IIS ワーカー プロセスが、アプリケーション プール B を対象とする ApplicationHost.config ファイル内の構成情報を読み取ることができるようにするために行われます。
ApplicationHost.config には、カスタム アプリケーション プール ID のユーザー名とパスワード、仮想ディレクトリのユーザー名とパスワードなどの機密情報が含まれている場合があります。 したがって、すべてのアプリケーション プールが ApplicationHost.config にアクセスできるようにすると、アプリケーション プールの分離が中断されます。 各アプリケーション プールが ApplicationHost.config ファイルに直接アクセスできる場合、これらのプールは次のコマンドを実行して、他のアプリケーション プールから機密情報を簡単にハッキングできます。
appcmd list APPPOOL "DefaultAppPool" /text:*
IUSR - 匿名認証
匿名認証を使用すると、ユーザーはユーザー名やパスワードの入力を求められることなく、Web サイトのパブリック領域にアクセスできます。 IIS 7.0 以降のバージョンでは、組み込みのアカウント ( IUSR) を使用して匿名アクセスを提供します。 この組み込みアカウントにはパスワードは必要ありません。 匿名認証が有効な場合に使用される既定の ID になります。
ApplicationHost.config ファイルでは、次の定義を確認できます。
<authentication>
<anonymousAuthentication enabled="true" userName="IUSR" />
</authentication>
これは、IIS に対して、すべての匿名認証要求に新しい組み込みアカウントを使用するように指示します。 これを行う最大の利点は次のとおりです。
- このアカウントのパスワードの有効期限が切れるのを心配する必要がなくなりました。
- xcopy /o を使用して、ファイルを所有権と ACL 情報と共に異なるコンピューターにシームレスにコピーできます。
また、 IUSR アカウントではなく、特定の Windows アカウントまたはアプリケーション プール ID を使用して、Web サイトに匿名認証を提供することもできます。
IUSR と Connect
as 接続は IIS のオプションであり、Web サイトへのアクセスに使用する資格情報を決定できます。 認証されたユーザー資格情報または特定のユーザー資格情報を使用できます。 この違いを理解するには、次のシナリオを検討してください。
匿名認証を使用するように構成された既定の Web サイトがあります。 ただし、Web サイトのコンテンツは別のサーバー上にあり、 Connect as セクションを使用して、 Test ドメイン ユーザーを介してそのリソースにアクセスします。 ユーザーがログインすると、IUSR アカウントを使用して認証されます。 ただし、Web サイトのコンテンツには、「 Connect as 」セクションに記載されているユーザー資格情報を使用してアクセスします。
簡単に言うと、匿名認証は、Web サイトがユーザーを識別するために使用するメカニズムです。 ただし、この機能を使用する場合、ユーザーは資格情報を指定する必要はありません。 ただし、コンテンツがネットワーク共有上にあるのと同様のシナリオが存在する可能性があります。 このような場合は、組み込みのアカウントを使用してネットワーク共有にアクセスすることはできません。 代わりに、特定のアカウント (ドメイン) を使用してこれを行う必要があります。
ASP.NET なりすまし
文字通り、偽装とは、別の人物になりすます行為を意味します。 技術的には、アプリケーション コードを実行する ID を制御する機能を提供する ASP.NET セキュリティ機能です。 ASP.NET が認証され承認されたクライアントでコードを実行する場合に偽装が発生します。 IIS は、 IUSR アカウントを使用してリソースへの匿名アクセスを提供します。 要求が ASP.NET に渡されると、アプリケーション プール ID を使用してアプリケーション コードが実行されます。
アプリケーションが匿名認証を使用している場合、および次のいずれかの条件に該当する場合は、IIS コードと ASP.NET コードの両方で偽装を有効にすることができます。
-
IMPERSONATIONが無効になっている場合は、アプリケーション プール ID を使用してアプリケーション コードが実行されます。 -
IMPERSONATIONが有効になっている場合は、アプリケーション コードの実行にNT AUTHORITY\IUSRが使用されます。
IIS を使用して impersonation 有効にすると、アプリケーションの Web.config ファイルに次のタグが追加され、IIS 認証済みアカウントまたはユーザーになりすます: <identity impersonate="true" />
ASP.NET アプリケーションのすべてのページのすべての要求に対して特定のユーザーを偽装するには、そのアプリケーションの Web.config ファイルの <identity> タグにユーザー名とパスワード属性を指定します。
<identity impersonate="true" userName="accountname" password="password" />
ASP.NET コードを使用して偽装を実装するには、「ASP.NET アプリケーションでの偽装の実装 を参照してください。
Testローカル ユーザーを偽装しているテスト Web サイトの IIS ワーカー プロセスを開き、アプリケーション コードを実行する権限借用アカウントが見つかるかどうかを確認します。
アプリケーションのアプリケーション プール ID は ApplicationPoolIdentity に設定され、匿名認証は IUSR アカウントを使用して提供されます。 ProcMon を使用すると、偽装 ID を簡単にトレースできます。 たとえば、調べているw3wp.exe プロセスに対応する CreateFile イベントのいずれかを調べると、次のスクリーンショットに示すように、偽装アカウントを見つけることができます。
