IIS 7 以降での構成の概要

  • [アーティクル]

投稿者: Tobin Titus

要約

IIS 7 以降の構成システムは、分散型のクリア テキスト XML ファイルに基づいており、IIS、ASP.NET、その他のコンポーネントを含む Web サーバー プラットフォーム全体の構成設定を保持します。必要に応じて、Web コンテンツと共にコンテンツ ディレクトリで設定できます。 構成階層のさまざまなレベルは、コンピューター管理者によって、サイト管理者やアプリケーション開発者など、他のユーザーに委任される場合があります。 セキュリティで保護された既定値とすぐに使用できるロックダウンにより、構成設定への書き込みアクセスはコンピューター管理者のみに制限されます。ただし、高度で詳細なロック機能のおかげで、安全にロック解除したり、特定の構成設定の管理を Web 名前空間のスコープに応じてより多くのユーザーに委任したりすることができます。 システムには、以前のバージョンの IIS を使用した API レベルと、以前のバージョンの .NET Framework を使用した XML レベルへの下位互換性があります。 このドキュメントでは、新しい構成システムの概要について説明します。

はじめに

IIS の構成システムは、分散型のクリア テキスト XML ファイルに基づいており、IIS、ASP.NET、その他のコンポーネントを含む Web サーバー プラットフォーム全体の構成設定を保持します。必要に応じて、Web コンテンツと共にコンテンツ ディレクトリで設定できます。 構成階層のさまざまなレベルは、コンピューター管理者によって、サイト管理者やアプリケーション開発者など、他のユーザーに委任される場合があります。 セキュリティで保護された既定値とすぐに使用できるロックダウンにより、構成設定への書き込みアクセスはコンピューター管理者のみに制限されます。ただし、高度で詳細なロック機能のおかげで、安全にロック解除したり、特定の構成設定の管理を Web 名前空間のスコープに応じてより多くのユーザーに委任したりすることができます。 システムには、以前のバージョンの IIS を使用した API レベルと、以前のバージョンの .NET Framework を使用した XML レベルへの下位互換性があります。

新しい構成システムは、次のように設計されています。

  • シンプル: すべての状態はファイルにあります。独自のストアは使用されません。構成状態の実際のマスターであるメモリ内構成データベースはありません (IIS 6.0 の IISADMIN サービスとは異なる点です)。スキーマはデータドリブンであり、100% 宣言型で検出可能です。

  • 低く抑えられた TCO: 構成は Web コンテンツと共にコピーできます。オプションの委任された管理により、すべての構成変更にコンピューターの管理者が関与する必要がなくなります。IIS、ASP.NET、その他の Web サーバー プラットフォーム全体にわたる構成設定とモデルの統合により、同じツールと API のセットを使用してサーバーを管理するためのワンストップ ショップが提供されます (たとえば、web.config ファイルには IIS と ASP.NET の設定の両方が含まれる場合があり、認証、認可、カスタム エラーなどの機能を制御するための 1 つの場所があります)。バックアップ、復元、セキュリティ管理 (ACL) は、標準のファイル システム ツールとプロセスに基づいています。

  • 安全: IIS がインストールされると、構成状態は、コンピューター管理者のみがアクセスできる、保護された 1 つのファイル内で管理されます。委任は既定では有効になっていません。既定では、機密情報 (パスワードなど) は保存されません。機密情報を構成ファイルに書き込む必要がある場合は、ディスク上で自動的に暗号化されます。アプリケーションごとの構成は、他のアプリケーションが設定を共有したり読み取ったりできないように、専用ファイル (ファイル システム ACL によって保護される) で、サンドボックス化および分離できます。

  • 拡張可能: スキーマの追加は、単に XML ファイルを schemas フォルダーにドロップするだけ行えます。スキーマを拡張するために API を呼び出したり、ツールを実行したりする必要はありません。設定は "セクション" と呼ばれる論理的に関連するブロックに編成され (.NET Framework 構成とまったく同じ)、新しいセクションの追加は簡単です (.NET Framework 構成とは異なり、コードを記述する必要はありません)。サーバー モジュールまたはアプリケーションからのカスタム セクション設定の読み取りは簡単です。

  • 互換性: 既存の IIS アプリケーションは、管理ベース オブジェクト (ABO)、IIS ADSI プロバイダー、IIS 6.0 WMI プロバイダーなどのインターフェイスを引き続き呼び出すことができます。既存の .NET Framework アプリケーションでは、System.Configuration や System.Web.Configuration などのインターフェイスを引き続き呼び出すことができます。machine.config と web.config の XML 形式に慣れているユーザーは、これらのファイルで同じ形式と構文を引き続き使用できます。また、同じ形式とモデルに従う IIS 設定を手動で編集することもできます。IIS メタベースのプロパティ名に慣れているユーザーは、新しい IIS 7.0 以降の構成ファイル内のプロパティに同じ名前が付けられているので、使用しやすいでしょう。

クリーン スキーマ

構成のスキーマを示す例を次に示します。

IIS 6 と IIS 7.0 以降での認証設定の編成方法を示します。

Note

IIS 6.0 の概念に慣れていないユーザーは、IIS 6.0 との比較を無視し、IIS 7.0 以降の概念と利点のみをお読みください。

まず、構成がファイルに保持される方法を比較し、次にスキーマ定義を見ていきます。

構成ファイル自体で、次の手順を実行します。

//
// Snippet from IIS 6.0 Metabase.xml
//
<IIsWebService    Location ="/LM/W3SVC"
      ... many lines here ...
    AuthFlags="AuthAnonymous"
      ... many lines here ...
    >
</IIsWebService>
<IIsWebDirectory    Location ="/LM/W3SVC/1/ROOT/aspnet_webadmin/2_0_41016"
    AuthFlags="AuthAnonymous | AuthNTLM"
    >
</IIsWebDirectory>
<IIsWebVirtualDir    Location ="/LM/W3SVC/Info/Templates/Public Web Site/Root"
        AuthFlags="AuthAnonymous"
    >
</IIsWebVirtualDir>

//
// Snippet from IIS 7.0 applicationHost.config
//
<anonymousAuthentication enabled="true"  userName="…"  password="…" />
<basicAuthentication enabled="false" />
<clientCertificateMappingAuthentication enabled="false" />
<windowsAuthentication enabled="true" >
    <providers>
        <add value="Negotiate" />
        <add value="NTLM" />
    </providers>
</windowsAuthentication>

重要なポイント :

  • IIS 6.0 では、非常に長い "フラットな" プロパティの一覧が使用されています。 プロパティの階層化またはグループ化はされていません。 同じリスト内の数百の設定の中から構成設定を検索するのは困難です。 IIS 7.0 以降では、セクションとセクション グループの階層と、セクション内のサブ要素が使用されます。 認証設定は、認証セクション グループまたは特定の認証セクションで検索することで簡単に見つけられます。
  • IIS 6.0 では、フラグを使用して認証スキームを設定しています。 IIS 7.0 以降では、認証スキーマごとにセクションが使用され、それぞれに enabled="true|false" が設定されています。 一部の認証スキームにのみ関連する追加設定は、関連するセクションでのみ設定できます (たとえば、ユーザー名とパスワードは匿名認証にのみ設定できます)。
  • IIS 6.0 では、メタベース ファイル内のパスを使用して構成レベル (サービス、仮想ディレクトリ、物理ディレクトリ) を指定しています。 サーバー全体の構成は、1 つのファイルに含まれています。 IIS 7.0 以降では既定で 1 つのファイルが使用されますが、ユーザーはコンテンツ ディレクトリ内の分散 web.config ファイルを利用して、スコープの構成設定を指定できます。
  • IIS 6.0 では、自己記述型の構成設定を行うために、長いプロパティ名が使用されています。 これは、ファイルの読みやすさを向上させ、ユーザーがプロパティの動作を理解するのを助けようとしています。 IIS 7.0 以降では短い名前が使用されますが、常に特定のセクションのコンテキスト、またはセクション内のサブ要素でも使用されます。
  • IIS 6.0 では、multi-sz (1 つの文字列プロパティのコンマ区切り要素) とフラグを使用して、NTAuthenticationProviders などの複数の要素値を処理しています。 IIS 7.0 以降では、.NET Framework の構成とまったく同じように、単純な追加/削除/クリア構文を持つコレクションが使用されます。 これにより、階層の下位レベルでは、必要な要素のみを追加 (または削除) できます。つまり、その要素が含まれる (または含まない) データ全体を重複させずに済みます。 また、ファイルの読みやすさも向上します (直接編集する際のヒューマン エラーが少なくなります)。

スキーマ ファイルで次の手順を実行します。

//
// Snippet from IIS 6.0 MBSchema.xml
//
<Property InternalName="AuthFlags" ID="6000" Type="DWORD" UserType="IIS_MD_UT_FILE" Attributes="INHERIT" >
    <Flag   InternalName="AuthAnonymous"   Value="1"   ID="6218"   />
    <Flag   InternalName="AuthBasic"             Value="2"   ID="6219"  />
    <Flag   InternalName="AuthNTLM"            Value="4"   ID="6220"  />
    <Flag   InternalName="AuthMD5"              Value="16"  ID="6221"  />
    <Flag   InternalName="AuthPassport"        Value="64"  ID="6299"  />
</Property>

//
// Snippet from IIS 7.0 IIS_Schema.xml
//
<sectionSchema name="system.webServer/security/authentication/basicAuthentication">
  <attribute name="enabled" type="bool" defaultValue="false" />
  <attribute name="realm" type="string" />
  <attribute name="defaultLogonDomain" type="string" />
  <attribute name="logonMethod" type="enum" defaultValue="ClearText">
    <enum name="Interactive" value="0" />
    <enum name="Batch" value="1" />
    <enum name="Network" value="2" />
    <enum name="ClearText" value="3" />
  </attribute>
</sectionSchema>

重要なポイント :

  • IIS 6.0 では、ID (数値) を使用して設定を識別します。 IIS 7.0 以降では、読みやすい文字列で設定に名前を付けます。
  • IIS 6.0 では、UserType などの直感的でない概念と、InternalName などの用語が使用されています。 IIS 7.0 以降では、アプリケーションだけでなく、人間にも読める、意味のあるわかりやすい名前が使用されています。

構成ファイルの階層

構成の "マスター" 状態は常に構成ファイルです (インメモリ構成データベースだった IIS 6.0 とは異なります。ディスクに定期的にフラッシュされていました)。

ルート (またはグローバル) レベルには、次の 2 つの個別のファイルがあります。

  • system32\inetsrv\config\applicationHost.config: Web サーバー (IIS) 設定のグローバル既定値を保持します。
  • \windows\microsoft.net\framework\v2.0.50727\config\machine.config: ASP.NET 設定の一部を含め、.NET Framework 設定のグローバル既定値を保持します (残りの設定は、同じフォルダーの web.config (ルート web.config と呼ばれる場合もあります) にあります)。

2 つの異なるファイルが存在する理由は、2 つのテクノロジのバージョンが異なるためです (スケジュール別および製品別)。 IIS は Windows の一部であり、.NET Framework は Visual Studio リリースの一部として別個にバージョン管理されます。

Web コンテンツ ディレクトリに、階層レベルと下位の動作を制御するオプションの web.config ファイルが存在する場合があります。 これらはローカルにすることもリモートにすることもできます (たとえば、コンテンツ ディレクトリが UNC 共有にある場合)。 これらに IIS、ASP.NET、またはそのレベルで指定できるその他の .NET Framework 構成設定を含めることができます。 既定では、web.config ファイルはありません。

継承階層の観点では、ルート ファイルは machine.config、次が同一ディレクトリ内の web.config (ルート web.config と呼ばれる)、次が applicationHost.config、次が名前空間を伴うオプションの web.config ファイルです。

構成にファイルを含める

場合によっては、web.config ファイルに他の .config ファイルを含めるのが便利です。 これは、configSource 属性を使用して行います。 現時点では、セキュリティ上の理由から、サブディレクトリ内の相対物理パスを指すように制限されています (つまり、ファイル A は、B が A の物理サブディレクトリにある場合にのみファイル B を含めることができます)。 configSource の使用方法を示す基本的な例を次に示します。

<!-- in inetsrv\applicationHost.config -->
<configuration>
  <system.webServer>
  
    <!-- mimemaps moved by the customer to a different file -->
    <!-- so that this file is shorter and more readable -->
    <staticContent configSource="staticContent.config"/>
  
    <!-- the rest of system.webServer sections are here… -->
  </system.webServer>
</configuration>
  
<!-- in inetsrv\staticContent.config -->
<configuration>
  <system.webServer>
    <staticContent>
      <!-- all the mimemap definitions are here -->
      <mimeMap ….. />
      <mimeMap ….. />
      <mimeMap ….. />
    </staticContent>
  </system.webServer>
</configuration>

この例では、お客様は staticContent セクションの内容を別のファイルに移動して、より短く読みやすく、applicationHost.config を作成したいと考えていました。

.config ファイルで構成設定が変更されると、サーバーは自動的に変更を取得し、その変更に対応します。 お客様は、アプリケーションまたはアプリケーション プールまたはサーバー全体のリサイクルについて心配する必要はありません (たとえば、変更された構成設定によっては、サーバー自体がアプリケーション プールをリサイクルする場合があります)。

設定の編成

構成ファイル (階層の特定のレベル) 内では、設定はフラット リストとしてではなく、構造化された方法で編成されます。 展開、登録、拡張の基本的な単位は、構成セクションになります。 セクションはセクション グループに含まれます。そのセクション グループは、さらにその親セクション グループに含まれる場合があります。 セクション自体は入れ子になりません。 セクション グループは次のとおりです。

applicationHost.config の例を次に示します。

<!-- section group for web server configuration -->
<system.webServer>
  
  <!-- section group for web server security configuration -->
  <security>
    <!-- section group for web server authentication configuration -->
    <authentication>
  
      <!-- three sections for authentication -->
  
      <basicAuthentcation ... />
      <windowsAutnentication ... />
      <anonymousAuthentication ... />
    </authentication>
  </security>
</system.webServer>

構成設定は必ず特定のセクションに属します。

セクション グループは、構造化するためにのみ存在します。セクション グループを直接設定することはできません。セクションのみ設定できます。

セクション内の構造は次のとおりです。

  • 構成要素: 構成設定が含まれます。その他の構成要素が含まれる場合もあります。 XML 要素として表されます。 セクションも要素です。
  • 構成コレクション: 構成要素のプライベート ケース。構成要素の一覧を add/remove/clear (コレクション ディレクティブと呼ばれます) の形式で格納します。 <add>、<remove>、<clear> サブ要素を含む XML 要素として表されます。
  • 構成プロパティ: これは [リーフ] 構成設定です。 XML 属性として表されます。

applicationHost.config の例を次に示します。

<!-- "windowsAuthentcation" is a section which is an element -->
<!-- "enabled" is a property -->
<windowsAuthentication enabled="true">
  
  <!-- "providers" is a collection which is an element -->
  <providers>
  
    <!-- the collection contains two elements -->
    <!-- "add" is the collection directive; "value" is the property -->
    <add value="Negotiate"/>
    <add value=""NTLM/>
  </providers>
</windowsAuthentication>

既定では、applicationHost.config には、system.applicationHost と system.webServer という 2 つのメイン セクション グループが含まれています。 また、<configSections> と呼ばれるセクションも含まれています。これは、他のすべてのセクションを登録するために構成システムによって内部的に使用されるという点で特別です。

既定では、machine.config には複数のセクション グループが含まれています。 ASP.NET 設定は、system.web セクション グループにあります。

場所タグと構成ファイル

多くの場合、コンテンツ ディレクトリ内の web.config ファイルは避け、グローバルな既定値をオーバーライドする URL ごとに構成することが望ましいです。 たとえば、管理者は、特定のサイトで何らかの認証スキームを使用する必要があり、サイト管理者 (およびそのサイトのアプリケーション開発者) がそれをオフにできないように指定したいと考えるかもしれません。

これを実現する最も簡単な方法は、場所タグを使用することです。 これは、仮想パスにマップされたフォルダーに web.config を使用せずに、特定のパスの構成を指定するメカニズムです。

この例では、applicationHost.config 内で場所タグを使用する方法を示します。

<!-- the following will take effect on MyAdminSite -->
<location path="MyAdminSite">
  <system.webServer>
    <security>
      <authentication>
        <basicAuthentication enabled="false"/>
        <windowsAuthentication enabled="true"/>
        <anonymousAuthentication enabled="false"/>
      </authentication>
    </security>
  </system.webServer>
</location>

グローバル レベル (path=".")、サイト、またはサイト内の特定のパスの構成を指定するために、場所タグを使用できます。 ファイルには複数の場所タグを含めることができます。 場所タグは、applicationHost.config や machine.config だけでなく、任意の .config ファイルに含めることができます。

場所タグは、セクションのロックとロック解除にも使用できます。 詳細については、構成ロック ラボを参照してください。

次のようなケースでは、場所タグを使用する代わりの方法がありません。

  • 同じ物理フォルダーにマップされた 2 つ以上の仮想パス。 明らかに、2 つの仮想パスの構成が異なる場合は、web.config ファイルで指定できません。共有されているためです。
  • ファイル固有の構成。 ファイルごとの web.config ファイルはありません。フォルダー全体に対するもののみです。

まとめ

このドキュメントでは、IIS 7.0 以降の構成システムに関する初期段階の概要について説明しました。 よりクリーンなスキーマ形式にスポットが当てられました。構成システムの分散型の性質、サイト所有者またはアプリケーション開発者への構成設定の委任を可能にする方法、構成ファイル内の設定の構造化された編成、IIS と ASP.NET 構成システムの統合について扱いました。

詳細については、残りの構成ドキュメント、特に構成イントリンシクスに関するドキュメントを確認することをお勧めします。そのドキュメントでは、設計やアーキテクチャなど、システムに関するより細部に迫ります。