IIS 7.0 構成の概要

作成者 :Tobin Titus

発行日 : 2007 年 11 月 22 日 (作業者 : saad)

更新日 : 2008 年 3 月 11 日 (作業者 : saad)

要約

IIS 7.0 では、新しい管理関連機能すべての中核に、最新の構成システムが導入されています。構成システムは、分散されたクリアテキストの XML ファイルをベースにしています。この XML ファイルは、IIS、ASP.NET、その他のコンポーネントなど、Web サーバー プラットフォーム全体の構成設定を保持します。また構成システムは、コンテンツ ディレクトリに Web コンテンツと共に設定することも可能です (任意)。コンピューター管理者は、さまざまなレベルの構成階層を、サイト管理者やアプリケーション開発者などのユーザーに委任できます。安全な既定値と特別な設定を必要としないロックダウン機能により、構成設定に対する書き込みアクセスがコンピューター管理者のみに制限されます。ただし、Web 名前空間の範囲では、高機能で細かい設定が可能なロック機能により、安全にロックを解除でき、その他のユーザーに対して特定の構成設定の管理を委任できます。システムは、API レベルでは旧バージョンの IIS と、XML レベルでは旧バージョンの .NET Famework と下位互換性があります。このドキュメントでは、新しい構成システムの一般的な概要を説明します。

この記事には次のような内容が含まれています。

  • はじめに

  • クリーンなスキーマ

  • 構成ファイルの階層

  • 設定の編成

  • location タグと構成ファイル

  • まとめ

はじめに

IIS 7.0 では、新しい管理関連機能すべての中核に、最新の構成システムが導入されています。構成システムは、分散されたクリアテキストの XML ファイルをベースにしています。この XML ファイルは、IIS、ASP.NET、その他のコンポーネントなど、Web サーバー プラットフォーム全体の構成設定を保持します。また構成システムは、コンテンツ ディレクトリに Web コンテンツと共に設定することも可能です (任意)。コンピューター管理者は、さまざまなレベルの構成階層を、サイト管理者やアプリケーション開発者などのユーザーに委任できます。安全な既定値と特別な設定を必要としないロックダウン機能により、構成設定に対する書き込みアクセスがコンピューター管理者のみに制限されます。ただし、Web 名前空間の範囲では、高機能で細かい設定が可能なロック機能により、安全にロックを解除でき、その他のユーザーに対して特定の構成設定の管理を委任できます。システムは、API レベルでは旧バージョンの IIS と、XML レベルでは旧バージョンの .NET Famework と下位互換性があります。

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

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

  

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

  

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

  

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

  

  • 互換性 : 既存の IIS アプリケーションは、引き続き Admin Base オブジェクト (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.0 および IIS 7.0 でどのように構成されるかがわかります。

: 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 構成とまったく同じように、単純な add/remove/clear 構文を持つコレクションを使用しています。これにより、下位レベルの階層は必要な要素のみを追加 (または削除) できます。必要な要素のある (ない) データ全体を複製する必要はありません。また、ファイルの可読性が大幅に向上し、直接編集するときの人的ミスが減ります。

スキマー ファイルの内容 :

//
// 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¥applicationHost.config : Web サーバー (IIS) 設定のグローバル既定値を保持します。
  • ¥windows¥microsoft.net¥framework¥v2.0.50727¥config¥machine.config : ASP.NET 設定の一部を含む、.NET Framework 設定のグローバル既定値を保持します (ASP.NET のその他の設定は、同じフォルダーの web.config (ルート web.config と呼ばれる場合もあります) に保存されます)。

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

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

継承の階層については、最上位のファイルは machine.config、続いて同じディレクトリの web.config (ルート web.config と呼ばれます)、そして applicationHost.config、最後に名前空間を持つ任意の web.config ファイルの順になります。

構成インクルード ファイル

場合によっては、web.config ファイルに他の .config ファイルをインクルードすると便利です。他のファイルをインクルードするには、configSource 属性を使用します。現在、セキュリティ上の理由から、サブディレクトリの相対物理パスのみを指定できます (たとえば、ファイル B がファイル A の物理サブディレクトリ内にある場合は、ファイル 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>

  

この例では、applicationHost.config をさらに短く読みやすくするために、ユーザーは staticContent セクションのコンテンツを別のファイルに移そうとしています。

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

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

location タグと構成ファイル

多くの場合、望ましいのは、コンテンツ ディレクトリにある web.config ファイルを使用しないで、グローバル既定値を上書きする URL ごとの構成を引き続き使用することです。たとえば、管理者は、特定のサイトが認証スキームを使用するように指定し、かつサイト管理者 (およびそのサイトのアプリケーション開発者) がその認証スキームを無効にできないように指定したいと思っているとします。

最も簡単な方法は、location タグを使用することです。これは、特定のパスに対して構成を指定するメカニズムで、仮想パスにマップされたフォルダーに web.config を格納する必要はありません。

次の例は、applicationHost.config でどのように location タグが使用されるかを示します。


<!-- 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>

  

location タグは、グローバル レベル (パス=".")、サイト、またはサイト内の特定のパスに対して構成を指定するために使用できます。1 つのファイルに複数の location タグを指定できます。location タグは、applicationHost.config や machine.config だけでなく、.config ファイルでも使用できます。

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

場合によっては、location タグを使用する以外にない場合があります。

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

  

まとめ

このドキュメントでは、IIS 7.0 の新しい構成システムに関して、初期段階の大まかな概要を説明しました。ここでは、よりクリアになったスキーマの形式、分散される構成システム、構成システムでサイト所有者またはアプリケーション開発者への構成設定の委任を可能にする方法、構成ファイルにおける設定の構造化された編成、および IIS と ASP.NET 構成システム間の統合を重点的に説明しました。

詳細については、その他の構成に関するドキュメント、特に、設計やアーキテクチャなどの、システムに関してより掘り下げた内容が記載された構成固有のドキュメントを参照することをお勧めします。

関連コンテンツ

記事