Appendix A: AD FS 2.0 要件レビュー

Active Directory フェデレーション サービス (AD FS) 2.0 展開に参加するパートナー組織が円滑に共同作業できるようにするには、まず、AD FS 2.0 のアカウント、名前解決、証明書に関する要件をサポートするように企業ネットワーク インフラストラクチャを構成する必要があります。AD FS 2.0 の要件は次のとおりです。

ハードウェア要件

Active Directory 2. 0 フェデレーション サービス コンピューターおよび Active Directory 2. 0 フェデレーション サービスp コンピューターに関するハードウェアの最小要件と推奨要件は、次のとおりです。

ハードウェア要件 最小要件 推奨要件
CPU 速度 シングルコア、1 ギガヘルツ (GHz) クアッドコア、2 GHz
RAM 1 GB 4 GB
ディスク容量 50 MB 100 MB

ソフトウェア要件

基本のインストール プラットフォームでは、AD FS 2.0 は、Windows Server 2008 または Windows Server 2008 R2 オペレーティング システムのいずれかを必要とします。AD FS 2.0 のインストール処理時、セットアップ ウィザードは、「AD FS 2.0 展開ガイド」の「AD FS 2.0 ソフトウェアのインストール」(英語) で説明されているように、前提となるアプリケーションおよび修正プログラムを自動的にチェックし、必要な場合はインストールします。

証明書要件

証明書は、フェデレーション サーバー、フェデレーション サーバー プロキシ、クレーム対応アプリケーション、および Web クライアント間の通信をセキュリティ保護するうえで最も重要な役割を果たします。このセクションで説明するように、フェデレーション サーバー コンピューターとフェデレーション サーバー プロキシ コンピューターのどちらをセットアップするかによって、証明書の要件は異なります。

フェデレーション サーバーの証明書

フェデレーション サーバーでは、次の表に示した証明書が必要です。

証明書の種類 説明 展開前に必要な知識
サーバー認証証明書 (AD FS 2.0 管理スナップインでは、Service Communication Certificate とも呼びます) これは標準の SSL (Secure Sockets Layer) 証明書で、フェデレーション サーバー、クライアント、およびフェデレーション サーバー プロキシ コンピューターの間の通信をセキュリティ保護するために使用されます。

AD FS 2.0 フェデレーション サーバー構成ウィザードを適切に実行するには、事前にこの証明書をインターネット インフォメーション サービス (IIS) でデフォルトの Web サイトにバインドする必要があります。

推奨事項: この証明書は AD FS 2.0 のクライアントによって信頼される必要があるため、VeriSign など公的な (サード パーティ) 証明機関 (CA) によって発行されたサーバー認証証明書を使用してください。

ヒント: この証明書のサブジェクト名は、展開する AD FS 2.0 の各インスタンスのフェデレーション サービス名を表すために使用されます。このため、新しい CA 発行証明書のサブジェクト名は、会社または組織の名前としてパートナーに最も通じやすい名前を選択するように考慮することをお勧めします。

トークン署名証明書 これは標準の X509 証明書で、フェデレーション サーバーが発行するすべてのトークンに安全に署名するために使用されます。 トークン署名証明書には秘密キーを含める必要があります。また、フェデレーション サービスの信頼されているルートにチェーン接続する必要があります。デフォルトでは、AD FS 2.0 は自己署名証明書を作成します。ただし、この証明書は、組織のニーズに応じて後から CA 発行証明書に変更できます。それには、AD FS 2.0 管理スナップインを使用します。
トークン解読証明書 これは標準の SSL 証明書で、パートナー フェデレーション サーバーによって暗号化された受信トークンを解読するために使用されます。また、この証明書はフェデレーション メタデータで公開されます。 デフォルトでは、AD FS 2.0 は自己署名証明書を作成します。ただし、この証明書は、組織のニーズに応じて後から CA 発行証明書に変更できます。それには、AD FS 2.0 管理スナップインを使用します。

トークン署名およびトークン解読に使用される証明書は、フェデレーション サービスが安定性を保つうえで欠かせない要素です。この目的で構成されている証明書が失われたり、意図せずに削除されたりすると、サービスの中断につながる可能性があるため、この目的で構成されている証明書はすべてバックアップする必要があります。

フェデレーション サーバーが使用する証明書の詳細については、「フェデレーション サーバーの証明書の要件」を参照してください。

フェデレーション サーバー プロキシの証明書

フェデレーション サーバー プロキシでは、次の表に示した証明書が必要です。

証明書の種類 説明 展開前に必要な知識
サーバー認証証明書 これは標準の SSL (Secure Sockets Layer) 証明書で、フェデレーション サーバー プロキシとインターネット クライアント コンピューターの間の通信をセキュリティ保護するために使用されます。

AD FS 2.0 フェデレーション サーバー プロキシ構成ウィザードを適切に実行するには、事前にインターネット インフォメーション サービス (IIS) で、この証明書をデフォルトの Web サイトにバインドする必要があります。

推奨事項: この証明書は AD FS 2.0 のクライアントによって信頼される必要があるため、VeriSign など公的な (サード パーティ) 証明機関 (CA) によって発行されたサーバー認証証明書を使用してください。

ヒント: この証明書のサブジェクト名は、展開する AD FS 2.0 の各インスタンスのフェデレーション サービス名を表すために使用されます。このため、サブジェクト名は、会社または組織の名前としてパートナーに最も通じやすい名前を選択するように考慮することをお勧めします。

フェデレーション サーバー プロキシが使用する証明書の詳細については、「フェデレーション サーバー プロキシの証明書の要件」を参照してください。

ブラウザー要件

JavaScript 機能に対応した最新の Web ブラウザーは、どれも AD FS クライアントとして動作させることができますが、デフォルトで提供される Web ページに関してテストを実施したブラウザーは、Internet Explorer バージョン 7.0/8.0、Mozilla Firefox 3.0、および Safari 3.1 Windows 版のみです。JavaScript を有効にする必要があります。また、ブラウザー ベースのサインインおよびサインアウトが適切に機能するためには、Cookie を有効にする必要があります。

マイクロソフトの AD FS 2.0 製品チームがテストに成功したブラウザーおよびオペレーティング システム構成を次の表に示します。

ブラウザー Windows 7 Windows Vista
Internet Explorer 7.0 X X
Internet Explorer 8.0 X X
FireFox 3.0 X X
Safari 3.1 X X

AD FS 2.0 が作成するセッション ベースの Cookie および固定 Cookie は、サインイン、サインアウト、シングル サインオン (SS0) などの機能を提供するために、クライアント コンピューターに格納する必要があります。したがって、クライアント ブラウザーは、Cookie を受け入れるように構成されている必要があります。認証に使用される Cookie は、常に、送信元サーバー用に記述された Secure HTTP (HTTPS) セッション Cookie です。クライアント ブラウザーがこの Cookie を許可するように構成されていない場合、AD FS 2.0 は正常に機能しません。固定 Cookie は、ユーザーによるクレーム プロバイダーの選択を保持するために使用されます。この Cookie は、AD FS 2.0 のサインイン ページの構成ファイルにある設定を使用して無効にすることができます。

セキュリティ上の理由から、TLS/SSL のサポートが必須です。

ネットワーク要件

組織に展開した AD FS 2.0 が正常に機能するには、以下に示すネットワーク サービスを適切に構成することが不可欠です。

TCP/IP ネットワーク接続

AD FS 2.0 が機能するためには、クライアント、ドメイン コントローラー、およびフェデレーション サービス、フェデレーション サービス プロキシ (使用する場合)、AD FS 2.0 Web Agent をホストするコンピューターが TCP/IP ネットワークで接続されている必要があります。

DNS

AD FS 2.0 の運用に欠かすことができない最も重要なネットワーク サービスとして、Active Directory ドメイン サービス (AD DS) に加えて、ドメイン ネーム システム (DNS) があります。DNS を展開すると、ユーザーは、わかりやすく覚えやすいコンピューター名を使用して、IP ネットワーク上にあるコンピューターやその他のリソースに接続できます。

nextref_longhorn では、Windows NT 4.0 ベースのネットワークで使用されていた Windows インターネット ネーム サービス (WINS) NetBIOS による名前解決に代わって、DNS を使用して名前解決を行います。WINS を必要とするアプリケーションでは、引き続き WINS を使用できます。ただし、AD DS および AD FS 2.0 では、DNS による名前解決を使用します。

AD FS 2.0 をサポートするための DNS 構成方法は、次に示す条件によって異なります。

  • 組織に DNS インフラストラクチャが既に存在するかどうか。ほとんどの場合、企業ネットワーク内の Web ブラウザー クライアントがインターネットにアクセスできるように、DNS は既にネットワーク上に構成されています。インターネット アクセスおよび名前解決は AD FS 2.0 の要件であるため、AD FS 2.0 の展開では、このインフラストラクチャが存在することが前提となります。

  • 企業ネットワークにフェデレーション サーバーを追加する予定があるかどうか。企業ネットワーク内のユーザーを認証するために、企業ネットワーク フォレストの内部 DNS サーバーは、フェデレーション サービスを実行している内部サーバーの CNAME を返すように構成されている必要があります。詳細については、「フェデレーション サーバーの証明書の要件」を参照してください。

  • 境界ネットワークにフェデレーション サーバー プロキシを追加する予定があるかどうか。アカウント パートナー組織の企業ネットワークにあるユーザー アカウントを認証する必要がある場合、その企業ネットワーク フォレストの内部 DNS サーバーは、内部Active Directory 2. 0 フェデレーション サービスpの CNAME を返すように構成する必要があります。Active Directory 2. 0 フェデレーション サービス プロキシの追加に対応するように DNS を構成する方法については、「フェデレーション サーバー プロキシの名前解決の要件」を参照してください。

  • テスト ラボ環境用に DNS をセットアップするかどうか。権限のあるルート DNS サーバーが 1 つも存在しないテスト ラボ環境で AD FS 2.0 を使用することを計画している場合は、名前のクエリが複数フォレスト間で適切に転送されるように、DNS フォワーダーの設定が必要になる可能性があります。AD FS 2.0 テスト ラボ環境のセットアップ方法に関する一般的な情報については、「AD FS 2.0 のステップ バイ ステップ ガイドとハウツー ガイド」(https://go.microsoft.com/fwlink/?LinkId=180357) (英語) を参照してください。

属性ストア要件

AD FS 2.0 には、ユーザーを認証し、それらのユーザーのセキュリティ クレームを抽出するために使用する属性ストアが少なくとも 1 つ必要です。AD FS 2.0 がサポートする属性ストアのリストについては、「AD FS 2.0 設計ガイド」の「属性ストアの役割(https://go.microsoft.com/fwlink/?LinkId=182464) を参照してください。

デフォルトでは、AD FS 2.0 は、Active Directory 属性ストアを自動的に作成します。

属性ストアの要件は、組織がアカウント パートナーとして機能する (フェデレーション ユーザーをホストする) か、リソース パートナーとして機能する (フェデレーション アプリケーションをホストする) かによって異なります。

AD DS

AD FS 2.0 が適切に機能するには、アカウント パートナー組織またはリソース パートナー組織のドメイン コントローラーが Windows Server 2003 SP1、Windows Server 2003 R2、または nextref_longhorn を実行している必要があります。

ドメインに属するコンピューターに AD FS 2.0 がインストールされ、構成されている場合、そのドメインの Active Directory ユーザー アカウント ストアは、選択可能な属性ストアとして利用できます。

スキーマ要件

AD FS 2.0 では、インターネット インフォメーション サービス (IIS) をインストールする必要があるため、セキュリティ上の理由から、実稼動環境のドメイン コントローラーには、AD FS 2.0 ソフトウェアをインストールしないことをお勧めします。ただし、この構成はマイクロソフト カスタマー サービス サポートによってサポートされています。

AD FS 2.0 では、AD DS のスキーマの変更や機能レベルの変更は必要ありません。

機能レベル要件

AD FS 2.0 を適切に動作させるために、AD DS の機能レベルを変更する必要はありません。

サービス アカウント要件

フェデレーション サーバー ファームを作成する場合は、まず、フェデレーション サービスで使用できる AD DS に、専用のドメイン ベースのサービス アカウントを作成する必要があります。その後、このアカウントを使用するためのファーム内の各フェデレーション サーバーを構成します。構成方法の詳細については、「AD FS 2.0 展開ガイド」の「フェデレーション サーバー ファームのサービス アカウントを手動で構成する」(英語) を参照してください。

LDAP

他の LDAP (ライトウェイト ディレクトリ アクセス プロトコル) ベースの属性ストアを操作する場合は、Windows 統合認証をサポートする LDAP サーバーに接続する必要があります。RFC 2255 で説明されているように、LDAP 接続文字列も LDAP URL の形式で記述する必要があります。

SQL Server

AD FS 2.0 が適切に機能するためには、SQL (構造化照会言語) Server の属性ストアをホストするコンピューターで、Microsoft SQL Server 2005 または SQL Server 2008 が実行されている必要があります。SQL ベースの属性ストアを操作する場合は、接続文字列も構成する必要があります。

カスタム属性ストア

高度なシナリオに対応するために、カスタム属性ストアを開発することができます。AD FS 2.0 に組み込まれているポリシー言語はカスタム属性ストアを参照できるため、次のような拡張されたシナリオが可能になります。

  • ローカルで認証されたユーザーのクレームを作成する

  • 外部で認証されたユーザーのクレームを補足する

  • ユーザーがトークンを取得することをを承認する

  • サービスがユーザーの行動に基づいてトークンを取得することを承認する

カスタム属性ストアを処理する際、接続文字列を構成することが必要になる場合もあります。この場合、カスタム属性ストアへの接続を可能にする任意のカスタム コードを入力できます。この場合の接続文字列は、カスタム属性ストアの開発者によって実装されたと解釈される名前/値のペアのセットです。

カスタム属性ストアの開発と使用に関する詳細については、「属性ストアの概要」(英語) を参照してください (https://go.microsoft.com/fwlink/?LinkId=190782)。

アプリケーション要件

フェデレーション サーバーは、クレーム対応アプリケーションなどのフェデレーション アプリケーションと通信し、保護することができます。AD FS 2.0 では、Windows NT トークン ベースのアプリケーションはサポートされません。

認証要件

AD FS 2.0 は、既存の Windows 認証 (Kerberos 認証、NTLM、スマート カード、X.509 v3 クライアント側証明書など) とシームレスに統合します。フェデレーション サーバーでは、ドメインに対するユーザーの認証に標準の Kerberos 認証を使用します。クライアントでは、認証の構成方法に応じて、フォーム ベース認証、スマート カード認証、および Windows 統合認証を使用できます。

AD FS 2.0 フェデレーション サーバー プロキシ ロールにより、ユーザーが SSL クライアント認証を使用して外部で認証を行うシナリオが可能になります。SSL クライアント認証を必須とするようにフェデレーション サーバー ロールを構成することもできますが、一般的には、Windows 統合認証を使用するようにアカウント フェデレーション サーバーを構成することにより、ユーザーにとって最もシームレスな認証方法が提供されます。この場合、ユーザーが Windows デスクトップ ログオンでどのような資格情報を使用するかについて、AD FS 2.0 で制御することはできません。

スマート カード ログオン

AD FS 2.0 では、自身が認証に使用する資格情報の種類 (パスワード、SSL クライアント認証、または Windows 統合認証) を強制的に指定することはできますが、スマート カードによる認証を直接的に強制することはありません。したがって、スマート カードの暗証番号 (PIN) 資格情報を取得するためのクライアント側ユーザー インターフェイス (UI) も、AD FS 2.0 では提供されません。これは、Windows ベースのクライアントがActive Directory 2. 0 フェデレーション サービスや Web サーバーにユーザーの資格情報の詳細を提供しないように意図されているためです。

スマート カード認証

スマート カード認証では、Kerberos プロトコルを使用してアカウント Active Directory 2. 0 フェデレーション サービスへの認証を行います。AD FS 2.0 の機能を拡張して新しい認証方式を追加することはできません。スマート カードの証明書は、クライアント コンピューター上の信頼されたルートにチェーン接続する必要はありません。スマート カード ベースの証明書を AD FS 2.0 で使用するには、次の条件を満たす必要があります。

  • スマート カードのリーダーおよび暗号化サービス プロバイダー (CSP) が、ブラウザーが置かれているコンピューターで機能すること。

  • スマート カードの証明書が、アカウント Active Directory 2. 0 フェデレーション サービス上およびアカウント Active Directory 2. 0 フェデレーション サービスp上で信頼されたルートにチェーン接続できること。

  • 証明書が、次のいずれかの方法で AD DS のユーザー アカウントにマッピングされていること。

    • 証明書のサブジェクト名が、AD DS にあるユーザー アカウントの LDAP 識別名に対応する。

    • 証明書のサブジェクト別名拡張に、AD DS にあるユーザー アカウントのユーザー プリンシパル名 (UPN) が含まれている。

シナリオで特定の認証強度要件をサポートするために、ユーザーがどのように認証されたかを示すクレームを作成するように AD FS 2.0 を構成することもできます。証明書利用者は、認証の判定にこのクレームを使用できます。