IIS の ID について

この記事では、インターネット インフォメーション サービス (IIS) の ID に関する背景情報を提供します。

元の製品バージョン:インターネット インフォメーション サービス
元の KB 番号: 4466942

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

アプリケーション プール ID を理解するには、ID が何であるかを理解する必要があります。 簡単に言うと、ID は Windows アカウントです。 Windows で実行されるすべてのプロセスは、ID の下で実行されます。 アプリケーションは、Windows ID を使用してワーカー プロセスによって実行されます。 使用される Windows ID は、アプリケーション プール ID に依存します。これは、次のアカウントのいずれかになります。

• ローカル システム: 高い特権を持ち、ネットワーク リソースにもアクセスできる信頼されたアカウント。
• ネットワーク サービス: 標準の最小特権サービスの実行に使用される制限付きサービス アカウントまたは制限付きサービス アカウント。 このアカウントの特権は、ローカル システム アカウントよりも少なくなります。 このアカウントは、ネットワーク リソースにアクセスできます。
• ローカル サービス: ネットワーク サービスに似た制限付きまたは制限付きサービス アカウントで、標準の最小特権サービスを実行することを目的としています。 このアカウントには、ネットワーク リソースへのアクセス権がありません。
• 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

  

  MyWebAppZone イベント ログ (シナリオ 1 から) をチェックすると、次のエラー イベントがログに記録されます。 エラー メッセージが 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$
  

  この欠点を克服するには、カスタム 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ポイントすると、次のユーザーとグループがサイトのアクセス制御リストに自動的に追加されます。

ユーザー、グループ	許可されたアクセス
CREATOR OWNER	特別なアクセス許可
SYSTEM	フル コントロール
Administrators	フル コントロール
Users	実行 & 読み取り、フォルダーの内容の一覧表示、読み取り
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という名前になります。これらのファイルは、アプリケーション プールセキュリティ識別子 (SID) を使用 IIS APPPOOL\AppPoolName して、対応するアプリケーション プール内の 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 情報と共に別のコンピューターにシームレスにコピーできます。

また、アカウントではなく特定の Windows アカウントまたはアプリケーション プール ID を使用して、Web サイトに匿名認証を IUSR 提供することもできます。

IUSR と Connect

として接続は、Web サイトへのアクセスに使用する資格情報を決定できる IIS のオプションです。 認証されたユーザー資格情報または特定のユーザー資格情報を使用できます。 違いを理解するには、次のシナリオを検討してください。

匿名認証を使用するように構成されている既定の 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 を使用してアプリケーション コードを実行します。

impersonation IIS を使用して有効にすると、アプリケーションの Web.config ファイルに次のタグが追加され、IIS 認証アカウントまたはユーザー: <ID impersonate="true" />

ASP.NET アプリケーションのすべてのページのすべての要求に対して特定のユーザーを偽装するには、そのアプリケーションの Web.config ファイルのタグに <identity> ユーザー名とパスワード属性を指定します。

<identity impersonate="true" userName="accountname" password="password" />

ASP.NET コードを使用して偽装を実装するには、「ASP.NET アプリケーションに偽装を実装する」を参照してください。

ローカル ユーザーを偽装しているテスト Web サイトの IIS ワーカー プロセスをTest開き、アプリケーション コードを実行する権限借用アカウントを見つけることができるかどうかをチェックします。

アプリケーションのアプリケーション プール ID が ApplicationPoolIdentity に設定され、アカウントを使用 IUSR して匿名認証が提供されます。 ProcMon を使用すると、偽装 ID を簡単にトレースできます。 たとえば、調査中の w3wp.exe プロセスに対応する CreateFile イベントのいずれかを調べると、次のスクリーンショットに示すように偽装アカウントを見つけることができます。