共有構成とリモートプロビジョニング

[アーティクル]
03/01/2010

公開日: 2007 年 12 月 13 日 (作業者: walterov (英語))

更新日: 2009 年 1月 29 日 (作業者: walterov (英語))

リモートマシンからサイトプロビジョニングタスクを実行するような環境で IIS 7 共有構成を使用すると、"ダブルホップ認証の問題" として知られる問題に直面する可能性があります。この問題が発生すると、プロビジョニングタスクを実行できなくなります。この記事ではこの問題について取り上げ、その回避策を紹介します。

問題について

以下の図のようなプロビジョニングトポロジは、IIS 7 で利用可能な新しい共有構成機能の一般的なオプションの 1 つです。このトポロジでは、ネットワーク共有に構成を集中管理させ、集中プロビジョニングサーバーが複数の Web サーバーファームでプロビジョニング操作を行います。ここでは、すべての Web サーバーファームが Windows Server® 2008 で IIS 7 を実行していることを想定しています。

Ff454033.typical(ja-jp,TechNet.10).jpg
典型的なプロビジョニングトポロジ

以下のスクリーンショットに示すように、IIS マネージャーを使用すると簡単に共有構成を有効にできます。

Ff454033.sc-enabled(ja-jp,TechNet.10).jpg

IIS 7 には、新しいマネージ API である Microsoft.Web.Administration が用意されています。この API には、以下の図に示すように、ネットワークを介したリモート管理が可能な OpenRemote メソッドが含まれています。

Ff454033.remoteadmin(ja-jp,TechNet.10).jpg

以下のコードスニペットでは、OpenRemote を使用して、別の Web サーバー上でアプリケーションをプロビジョニングしています。

Ff454033.remote(ja-jp,TechNet.10).jpg

リモート Web サーバーの共有構成が有効な場合、このサンプルコードを実行すると以下のエラーが返されます。

Ff454033.error(ja-jp,TechNet.10).jpg

リモート Web サーバーが、共有構成ではなくローカル構成を使用していれば、この問題は生じません。

次のように、共有構成を無効にします。

Ff454033.sc-disable(ja-jp,TechNet.10).jpg

サンプルアプリケーションをもう一度実行します。

Ff454033.no-error(ja-jp,TechNet.10).jpg

変更は正常にコミットされました。

Ff454033.testshot(ja-jp,TechNet.10).jpg

これが、複数サーバーにまたがる共有構成によって引き起こされるダブルホップ認証の問題です。OpenRemote は、DCOM を通して COM オブジェクトをリモートから呼び出します。構成がローカル構成になっていない場合、COM オブジェクトは、COM 使用時には許可されていないダブルホップを試行します。この問題は、共有構成に書き込み操作を行う場合にのみ発生します。

読み込み操作の場合、基盤となる構成システムでは、redirection.config ファイルに保存された資格情報を使用しています。この資格情報により、リモートネットワーク共有サーバー上で認証を行うため、ダブルホップ問題は発生しません。一方、書き込み操作では、呼び出し側セキュリティトークンを使用して操作を実行しますが、このセキュリティトークンは、リモートネットワーク共有サーバーでは無効です。

回避策

オプション 1: 指定したアカウントを使用するように、構成 COM オブジェクトの DCOM 構成を修正する

構成 COM オブジェクトに関するダブルホップの問題を回避するには、呼び出し側のセキュリティコンテキストに頼らず、指定のアカウントを使用するように DCOM 構成を変更する必要があります。リモートネットワーク共有サーバーで、指定の資格情報を使用して構成 COM オブジェクト認証を行えるようにします。
IIS 7 構成 COM オブジェクトである [ahadmin] は、リモート Web サーバーのコンポーネントサービスの [DCOM 構成] の下にあります。以下の図をご覧ください。

Ff454033.ahadmin(ja-jp,TechNet.10).jpg

[ahadmin] ノードを右クリックし、[プロパティ] を選択します。[識別] タブを選択し、[起動したユーザー] オプションではなく [指定したユーザー] オプションをオンにします。続いて、以下のようにユーザーアカウントにアクセス許可を指定します。

ネットワーク共有サーバーの共有構成ファイルに対する "変更" アクセス許可を付与する。
system32\inetsrv\config に保存される redirection.config ファイルに対する "読み取り" アクセス許可を付与する。
ローカル管理グループに所属させる。所属させない場合、"解読不能" の例外が発生します。

Ff454033.ahadmin-ok(ja-jp,TechNet.10).jpg

[OK] をクリックします。

変更後、サンプルアプリケーションを再び実行します。今度は、正常に実行できます。

Ff454033.no-error2(ja-jp,TechNet.10).jpg

これで、テストアプリケーションは正常にプロビジョニングされました。

Ff454033.testshot2(ja-jp,TechNet.10).jpg

構成 COM オブジェクトに指定したアカウントを使用すると、余計なセキュリティリスクを抱える危険があります (たとえば、COM オブジェクトを呼び出せるアクセス許可があれば、どのユーザーでも構成を変更できます)。このセキュリティリスクを減らすには、プロビジョニングのこのオプション 1 を使用して、Web サーバーファーム内で Web サーバーを 1 台だけ構成し、ファイアウォールの設定によってこの Web サーバーへのアクセスを特定の IP に制限します。

セキュリティ上の警告

このアプローチでは、コンポーネントが呼び出し側のセキュリティコンテキストの下で実行されないので、管理者以外でもサーバーに対して管理者レベルの変更を加えられるという危険があります。

オプション 2: ホスティングサービスのサンプルアプローチを使用する

このオプションは、DCOM 呼び出しによる OpenRemote を使用せずに、代わりにホスティングサービスコードサンプルのようなサービスを作成する方法です。このサービスは、WCF (Windows Communication Foundation) 上に構築される Web サービスで、以下の図のように Web ファーム内の Web サーバーの 1 つに配置されます。
Ff454033.servicessample(ja-jp,TechNet.10).jpg
IIS 7 でホスティングを行いたくないユーザーは、Windows サービスを使用してサービスをホスティングできます。Web サービスは Microsoft.Web.Administration API を基盤としており、統合性に優れています。また、OpenRemote の場合のようにファイアウォールを開く必要はありません。

セキュリティに関する検討事項

権限を与えられたユーザーが認証された場合のみ、サービスの呼び出しを行えるようにして、サービスを保護する必要があります。

オプション 3: WMI の使用

ダブルホップの問題を避けるもう 1 つのオプションは、以下の図のように WMI サービスを使用する方法です。

WMI サービスでは、リモート Web サーバーへ接続するための資格情報を指定できます。以下のコードスニペットに示すように、リモートサーバー上の WMI サービスは、プロビジョニングオプションを実行している間、ID を偽装します。共有構成での操作を有効にするには、リモートサーバー上の WMI への接続時に偽装オプションを指定します。WMI を使用する場合は、リモート呼び出しが実行できるようにファイアウォールの特定のポートを開放する必要があります。
Ff454033.WMI(ja-jp,TechNet.10).jpg

共有構成とリモート プロビジョニング