Microsoft.com の内部Active Directory フェデレーション サービスを使用する

Jim Guthrie

マイクロソフトでは、エクストラネットを介してビジネス パートナーに重要な内部リソースへのアクセスを提供しています。このエクストラネットのアーキテクチャでは、組織の外部からの参加者が、このネットワーク用の一意のドメイン アカウントを保有している必要があります。

このアカウントは、当然パートナーではなくマイクロソフトの社員によって作成および管理されています。この方法は正常に機能していますが、ユーザーの操作性は不十分な場合があります。また、すべてのパートナー ユーザーの管理はマイクロソフトにとっても負担のかかる作業であり、多くのリソースが必要となります。

ここからは、このエクストラネットのしくみについて説明します。顧客やパートナーは、アプリケーションにサインインするときに、資格情報の入力を求められます。同一セッションの間、そのユーザーが異なるリソースにアクセスしようとすると、再び資格情報の入力が求められます。この動作は、ユーザーが異なるリソースにアクセスするたびに発生します。ユーザーは、複数のリソースを使用する 1 つのアプリケーション (財務データベースなど) にサインインした場合、異なるリソースにアクセスするたびに認証を行う必要があります。これはユーザーにとっては厄介で面倒な操作です。

幸いなことに、Active Directory® フェデレーション サービス (ADFS) を使用すると、この複数回にわたる認証の問題を非常に簡単に解決できます。ADFS は、Windows Server® 2003 R2 のコンポーネントです。ADFS を使用すると、複数の組織間の信頼を容易に作成し、各組織がそれぞれのユーザーを管理しつつ、複数のリソースを共有できるようになります。このコラムでは、マイクロソフトが ADFS をどのように使用して、このエクストラネットの複数のリソースへのアクセスに関する問題を解決するかについて説明し、同様のソリューションを実装する場合に必要な情報を提供します。詳細な説明に移る前に、図 1 を参照し、基本的な ADFS 用語を理解してください。

Figure 1 ADFS に関する用語

ADFS ソリューション

ユーザーが ADFS 対応のアプリケーションにアクセスしようとすると、領域の検出を行うための画面がフェデレーション サービス リソース (FS-R) によってブラウザに表示されます。ここでユーザーは、セッション中に使用する一連の資格情報を選択します。次にユーザーは、クライアントが選択した領域に基づいて、フェデレーション サービス アカウント (FS-A) サーバーにリダイレクトされます。ユーザーはこのサーバーから、Windows Live™ ID (旧称 Passport アカウント)、Windows 統合認証、または SSL 認証の形式で入力した資格情報に基づく有効なアカウント トークンを (Cookie として) 受信します (図 2 を参照)。このモデルでは、個々の組織が独自のアカウント フェデレーション サーバーを管理します。Microsoft パートナー サーバーの場合は、これによって Microsoft.com に環境内のすべてのアカウントを管理するための負担がかからなくなります。もちろん、そのような責任を与える場合には、フェデレーションを構成する組織を慎重に選択する必要があります。また、それらの組織がアカウント情報を能動的に管理していることを確認する必要があります。

図 2** ADFS の流れ **(画像を拡大するには、ここをクリックします)

処理は FS-R サーバーに戻り、ここでアカウント トークンがリソース トークンと交換されます。マイクロソフトの構成では、このリソース トークンには、FS-R で実行された要求マッピング プロセスでユーザーに与えられたアクセス許可の完全な一覧が含まれます。ユーザーは、このリソース トークンを受信すれば、セッションが開かれている間または既定の 24 時間 (この時間は変更できます) の間、ADFS 対応のアプリケーションにシングル サインオン (SSO) できます。この結果、これらの ADFS 対応のアプリケーションに対する SSO が可能になり、ユーザー操作の安全性および効率性が向上します。ADFS 認証プロセスのすべての手順については、TechNet Magazine 2006 年 7 月号の Matt Steele の記事「ADFS を使用してシングル サインオンを簡略化する」を参照してください。**

マイクロソフトの社内リソースのセキュリティを維持するため、エクストラネットの中で、インターネットに接続されるネットワークを、社内ネットワークに接続されるネットワークから分離しました。つまり、各サーバーをデュアルホーム化することができました。必要な保護を提供するために、社内ユーザーからの一方向の信頼関係を許可し、これらのサーバーにアクセスできるようにしました。また、エクストラネット内では、必要なリソースへのアクセスを外部ユーザーに提供するためのドメインを別個に構成しています。

実装における 2 つの懸念事項は、負荷分散と ADFS ポリシー ファイルの変更でした。負荷分散は、グローバル レベルとローカル レベルの両方で課題となっていました。運用環境では、2 つの地域のフロントエンド Web サーバー クラスタで、コンテンツ配信ネットワーク (CDN) パートナーの Akamai または Savvis によって提供されるグローバル負荷分散を使用する予定です。これにより、万一 2 つの地域のサーバーが両方ともオフラインになった場合でも、エンド ユーザーは引き続きシステムにアクセスすることができます。この動作は、CDN によって提供されるサーバーの状態確認サービスに基づいた、フェールオーバーの自動化によって実現されます。また、後からクラスタを容易に追加することもできます。コスト削減のため、非運用環境への展開時には CDN サービスを使用しませんでした。

地域レベルでは、ローカル フェールオーバーを行うために、ネットワーク負荷分散 (NLB) クラスタを構成しました。特別な負荷分散機能は使用していないため、ハードウェアでも容易にローカル フェールオーバーを実現できますが、コスト削減のために NLB を使用しています。この構成により、サポートされるすべての環境で 99.9% を超える稼働時間を確保できる安定性が提供されます。

もう 1 つの課題は、ADFS の重要な要素である ADFS ポリシー ファイルが環境全体に正しく配布され、そのファイルへの変更も同様にレプリケートされるようにすることです。これを実現するために、Windows Server 2003 R2 に組み込まれたもう 1 つの機能である、分散ファイル システム レプリケーション (DFS-R) を使用します。この機能は、状態ベースの新しいマルチマスタ レプリケーション エンジンです。各バックエンド サーバーは、常にフル メッシュ レプリケーションを実行する DFS-R グループのメンバとして構成しました。これで、どのサーバーでポリシー ファイルが変更されても、すべてのサーバーにファイルを配布することができます。また、ファイルを変更できるユーザーを制御することにより、サービスの安定性と高い可用性を実現できます。

マイクロソフトでは、すべての変更を ADFS スナップインから行うことを試みました。しかし実際には、手動でこのファイルを更新する必要が生じることがあります。手動でポリシー ファイルを更新するときには、このファイルのバージョンが ADFS によって追跡されることを考慮する必要があります。したがって、変更が環境に反映されるように、次のようにファイルのバージョンを表す値を 1 増やす必要があります。

<TrustPolicyEntryUri>urn:federation:parttestint</TrustPolicyEntryUri> 
<TrustPolicyVersion>127
</TrustPolicyVersion> 

また、他のあらゆる XML ファイルと同様に、この XML ポリシー ファイルでも大文字と小文字が区別されることを考慮する必要があります。この XML ポリシー ファイルには、アプリケーションまたは他の ADFS サーバーへの参照が多数含まれており、それらの参照文字列はサーバー間で一字一字正確にコピーされる必要があります。次に一般的な例を示します。1 つ目の RevocationCheckFlags は手動で入力しますが、2 つ目の TrustPolicyEntryUri (信頼するアプリケーションの URL を表します) は UI から変更されます。

<RevocationCheckFlags>None
</RevocationCheckFlags>
<TrustPolicyEntryUri>https://adfstest.parttest.extranettest.microsoft.com/NTApp/
</TrustPolicyEntryUri>

セキュリティを強化するため、もう 1 つの ADFS コンポーネントであるフェデレーション サービス プロキシ (FS-P) を使用します。このコンポーネントを使用すると、受信インターネット要求から直接アクセスできない層に FS-R を配置することができます。Microsoft.com では、非運用環境で、1 つのプロキシを使用して複数の ADFS 環境をホストするという独自の方法でプロキシを実装しました。興味深いことに、このテクノロジの計画の初期段階で、レジストリ キーの簡単な変更だけでこの動作を実現できることがわかりました。このキーは、HKLM\Software\Microsoft\WebSSO にあります。このキーの初期ディレクトリの値を変更するだけで、プロキシを複数の環境で使用できるようになります。既定値は次のとおりです。

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”

環境を切り替えるには、キーを次のように変更します。

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”

バッチ ファイルを作成することで、この処理の管理を簡略化できます。残念ながら、ADFS 用の MMC スナップインの現在のバージョンでは、環境の切り替えはサポートされていません。これは、プロキシとリソース サーバーまたはアカウント サーバーとの間に一対一の関係があるためです。したがって、プロキシ サーバーを最大限に活用するには、バッチ ファイルを作成する必要があります。この結果、ホストする環境の数が増加しても、それに伴って物理サーバーの数を増やす必要がなくなるため、コストが大幅に削減されます。

アーキテクチャの観点から、マイクロソフトでは仮想コンピュータを使用して非運用環境を管理しています。これにより、さらにコストが削減されます。仮想コンピュータを使用することにより、6 台のサーバーを追加で購入し、そのためのスペースを確保したりする必要がなくなります。これまで、パフォーマンスの問題が発生したことはありません。ただし、運用環境ではさらに高速な処理が要求されるため、高性能の物理コンピュータを使用します。

Active Directory 以外の構成について

Microsoft.com では、認証に Active Directory アカウントを使用するだけでなく、Windows Live ID アカウントも使用できるようになりました。Windows Live ID (WLID) 4.5 を使用すると、要求を変換するしくみを独自に作成すれば、個々の Windows Live ID アカウントからマイクロソフトのリソースへのアクセスを委任できることがわかりました。これで特定のドメイン アカウントが不要になるため、SSO 認証を実現するうえで大きな利点が得られます。

今後の課題

現在の最大の課題は、トークン署名証明書を共有するための ADFS の管理です。現在は、通常 1 年後に更新が必要になる標準の証明書を使用しています。更新時には、対応する各サーバーの更新も必要になります。この作業は、FS-R に大きな影響を与えます。15 個または 20 個のフェデレーションであれば何とか管理できますが、マイクロソフトが考えている規模は、数千にまでは及びませんが少なくとも数百にはなります。この場合、各環境に SSL 証明書を管理する常勤のスタッフを配置する必要があります。このソリューションを自動化するための最善策を複数のチームで検討していますが、まだその方法は決まっていません。

残るもう 1 つの課題は、すべてのアプリケーションが既定で ADFS に対応しているわけではないということです。各サイトで ADFS の機能を利用するには、何らかのプログラムを作成する必要があります。現在、次世代の SharePoint で ADFS の実装要件がサポートされるように、Microsoft® Office SharePoint® Services チームと密接に協力しています。

まとめ

ADFS モデルへの移行を決定する際には、多くの要素について考慮する必要があります。1 つは、顧客がアクセスするリソースの数です。フェデレーションを構成している組織間の信頼を設定する処理は簡単ですが、条件に合ったアクセス ポリシーを作成、確認、および適用するには時間と労力がかかります。そのため、顧客がアクセスするリソースが 1 つしかない場合は、そうした労力を注ぐ価値があるかどうかを判断する必要があります。ただし、リソースの数の増加に伴って、メリットも増加します。

詳細については、「Windows Server 2003 R2 の Active Directory フェデレーション サービス (ADFS) の概要」および「Active Directory フェデレーション サービス : 統合された ID およびアクセス管理の実現」を参照してください。

Jim Guthrie は、マイクロソフトの Microsoft.com 運用チームに所属しています。彼は ADFS に関する仕事を担当しているだけでなく、エンタープライズ ポータル プラットフォーム サポート チームのシステム エンジニアでもあります。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.