付録 A:AD FS 要件の確認

  • [アーティクル]

Active Directory フェデレーション サービス (AD FS) 展開内で組織パートナーを適切に連携させるには、初めに、アカウント、名前解決、および証明書に関する AD FS の要件をサポートするように自社の企業ネットワーク インフラストラクチャが構成されていることを確認する必要があります。 AD FS には次の種類の要件があります。

ヒント

その他の AD FS リソースリンクについては、「AD FS の主要な概念」を参照してください。

ハードウェア要件

フェデレーション サーバーとフェデレーション サーバー プロキシ コンピューターには、次の最小および推奨のハードウェア要件が適用されます。

ハードウェア要件 最小要件 推奨要件
CPU 速度 シングルコア、1 GHz クアッドコア、2 GHz
RAM 1 GB 4 GB
ディスク領域 50 MB 100 MB

ソフトウェア要件

AD FS を使用するには、Windows Server® 2012 オペレーティング システムに組み込まれているサーバー機能が必要です。

注意

"フェデレーション サービス" と "フェデレーション サービス プロキシ" の 2 つの役割サービスを同じコンピューター上に共存させることはできません。

証明書の要件

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

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

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

証明書の種類 説明 展開前の注意事項
Secure Sockets Layer (SSL) 証明書 これは標準の Secure Sockets Layer (SSL) 証明書であり、フェデレーション サーバーとクライアントの間の通信のセキュリティ確保に使用されます。 この証明書は、フェデレーション サーバーまたはフェデレーション サーバー プロキシのインターネット インフォメーション サービス (IIS) において "既定の Web サイト" にバインドされている必要があります。 フェデレーション サーバー プロキシの場合は、このバインドを IIS で構成してからでなければ、フェデレーション サーバー プロキシ構成ウィザードを正常に実行することはできません。

推奨事項: この証明書は AD FS のクライアントによって信頼されていることが必要であるため、VeriSign などの公的 (第三者) 証明機関 (CA) 発行のサーバー認証証明書を使用してください。 ヒント: この証明書のサブジェクト名は、展開される AD FS のインスタンスそれぞれのフェデレーション サービス名を表すのに使用されます。 このような理由から、CA 発行の新しい証明書のサブジェクト名は、パートナーに対して自社または自組織の名前を最も良く表すものを選ぶことをお勧めします。
サービス通信証明書 この証明書は、フェデレーション サーバー間の通信のセキュリティを確保するための WCF メッセージ セキュリティに必要です。 既定の設定では、SSL 証明書がサービス通信証明書として使用されます。 これは、AD FS 管理コンソールで変更できます。
トークン署名証明書 これは標準の X509 証明書であり、フェデレーション サーバーが発行するすべてのトークンについて署名のセキュリティを確保するために使用されます。 トークン署名証明書には秘密キーが格納されている必要があります。また、フェデレーション サービスにおいて信頼されたルートまでチェーンでつながっている必要があります。 既定の設定では、AD FS によって自己署名証明書が作成されます。 必要であれば、これを後で CA 発行の証明書に変更できます。変更するには、AD FS 管理スナップインを使用します。
トークン暗号化解除証明書 これは標準の SSL 証明書であり、パートナーのフェデレーション サーバーによって暗号化されたトークンの暗号化解除に使用されます。 これは、フェデレーション メタデータでも公開されています。 既定の設定では、AD FS によって自己署名証明書が作成されます。 必要であれば、これを後で CA 発行の証明書に変更できます。変更するには、AD FS 管理スナップインを使用します。

注意事項

証明書のうち、トークン署名やトークン暗号化解除に使用されるものは、フェデレーション サービスの安定性を左右します。 この目的で構成された証明書が 1 つでも消失したり、予期せず削除されたりするとサービスが中断されるおそれがあるため、この目的で構成された証明書は必ずバックアップしてください。

フェデレーション サーバーで使用される証明書の詳細については、「フェデレーション サーバーの証明書の要件」をご覧ください。

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

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

証明書の種類 説明 展開前の注意事項
サーバー認証証明書 これは標準の Secure Sockets Layer (SSL) 証明書であり、フェデレーション サーバー プロキシとインターネット クライアント コンピューターの間の通信のセキュリティを確保するために使用されます。 この証明書は、インターネット インフォメーション サービス (IIS) において "既定の Web サイト" にバインドされている必要があります。このとおりでない場合は、AD FS フェデレーション サーバー プロキシ構成ウィザードを正常に実行することはできません。

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

ヒント: この証明書のサブジェクト名は、展開される AD FS のインスタンスそれぞれのフェデレーション サービス名を表すのに使用されます。 このような理由から、サブジェクト名は、パートナーに対して自社または自組織の名前を最も良く表すものを選ぶことをお勧めします。

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

ブラウザー要件

JavaScript 対応の現行の Web ブラウザーはどれでも、AD FS クライアントとして動作させることができますが、既定で用意される Web ページのテストが完了しているのは Windows 上の Internet Explorer バージョン 7.0、8.0、9.0、Mozilla Firefox 3.0、および Safari 3.1 のみです。 JavaScript が有効化されている必要があり、ブラウザー ベースのサインインとサインアウトを正しく動作させるために Cookie が有効化されている必要があります。

Microsoft の AD FS 製品チームによるテストが完了しているブラウザーとオペレーティング システムの構成を次の表に示します。

Browser Windows 7 Windows Vista
Internet Explorer 7.0 X X
Internet Explorer 8.0 X X
Internet Explorer 9.0 X テストせず
FireFox 3.0 X X
Safari 3.1 X X

注意

AD FS では、上の表に示したすべてのブラウザーについて、32 ビットと 64 ビットの両方のバージョンがサポートされます。

クッキー

AD FS によって作成されるセッションベースや永続的な Cookie がクライアント コンピューター上に保存される必要があります。これは、サインイン、サインアウト、シングル サインオンなどの機能を実現するためです。 したがって、クライアント ブラウザーは Cookie を受け入れるように設定されている必要があります。 認証に使用される Cookie はすべて HTTPS (Hypertext Transfer Protocol Secure) セッション Cookie であり、発信元サーバーごとに書き出されます。 クライアント ブラウザーがこの Cookie を受け入れるように設定されていない場合は、AD FS が正しく動作することができません。 永続的 Cookie は、ユーザーが選択したクレーム プロバイダーを記憶するために使用されます。 これを無効にするには、AD FS サインイン ページの構成ファイルにある構成設定を使用します。

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

ネットワークの要件

組織で AD FS を正常に展開するには、以下のネットワーク サービスを適切に構成することが非常に重要です。

TCP/IP ネットワーク接続

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

DNS

AD FS が動作するために不可欠なネットワーク サービスとして Active Directory Domain Services (AD DS) の次に挙げられるのが、ドメイン ネーム システム (DNS) です。 DNS が展開されているときは、ユーザーは覚えやすいフレンドリ コンピューター名を使用して IP ネットワーク上のコンピューターなどのリソースに接続することができます。

Windows NT 4.0 ベースのネットワークでは Windows Internet Name Service (WINS) NetBIOS 名前解決が使用されていましたが、Windows Server 2008 ではこれの代わりに DNS が使用されます。 アプリケーションで必要とされている場合は、WINS を引き続き使用できます。 しかし、AD DS と AD FS には DNS 名前解決が必要です。

AD FS をサポートするように DNS を設定するプロセスは、次の条件に該当するかどうかによって異なります。

  • 組織の DNS インフラストラクチャが既に存在する。 ほとんどのシナリオでは、DNS は組織のネットワーク全体で構成済みです。これは、企業ネットワーク内の Web ブラウザー クライアントがインターネットにアクセスできるようにするためです。 インターネット アクセスと名前解決は AD FS を使用するために必要であることから、このインフラストラクチャが存在することは AD FS 展開の前提条件となります。

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

  • フェデレーション サーバー プロキシを境界ネットワークに追加する予定がある。 アイデンティティ パートナー組織の企業ネットワークに存在するユーザー アカウントを認証できるようにするには、内部フェデレーション サーバー プロキシの CNAME を返すように企業ネットワーク フォレスト内の内部 DNS サーバーが構成されている必要があります。 フェデレーション サーバー プロキシの追加に対応するように DNS を構成する方法については、「フェデレーション サーバー プロキシの名前解決の要件」をご覧ください。

  • テスト ラボ環境用に DNS をセットアップしようとしている。 AD FS をテスト ラボ環境で使用する予定であり、その環境に権威ルート DNS サーバーが 1 つもない場合は、DNS フォワーダーをセットアップすることが必要になる可能性があります。これは、名前のクエリを 2 つ以上のフォレスト間で適切に転送するためです。 AD FS をテスト ラボ環境でセットアップする方法に関する一般的な情報については、「AD FS ステップ バイ ステップ ガイドとハウツー ガイド」を参照してください。

属性ストアの要件

AD FS を使用するには、ユーザーを認証してそのユーザーのセキュリティ要求を抽出するための属性ストアが少なくとも 1 つ必要です。 AD FS でサポートされる属性ストアの一覧については、AD FS 設計ガイドの「属性ストアの役割」をご覧ください。

注意

AD FS の既定の設定では、Active Directory 属性ストアが自動的に作成されます。

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

AD DS

AD FS が適切に動作するには、アカウント パートナー組織とリソース パートナー組織のどちらの場合も、ドメイン コントローラーで Windows Server 2003 SP1、Windows Server 2003 R2、Windows Server 2008、または Windows Server 2012 が実行されている必要があります。

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

重要

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

スキーマの要件

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

機能レベルの要件

AD FS の機能のほとんどは、AD DS の機能レベルを変更しなくても正常に動作します。 ただし、クライアント証明書認証の証明書が明示的に AD DS 内のユーザー アカウントにマッピングされている場合に認証を正しく動作させるには、ドメイン機能レベルが Windows Server 2008 以上であることが必要です。

サービス アカウントの要件

フェデレーション サーバー ファームを作成する場合は、最初に、AD DS 内にフェデレーション サービス専用のドメインベース サービス アカウントを作成する必要があります。 後で、このアカウントを使用するようにファーム内の各フェデレーション サーバーを構成します。 この方法の詳細については、AD FS 展開ガイドの「フェデレーション サーバー ファームのサービス アカウントを手動で構成する」をご覧ください。

LDAP

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

SQL Server

AD FS が正しく動作するには、SQL (構造化照会言語) Server 属性ストアをホストするコンピューターで Microsoft SQL Server 2005 または SQL Server 2008 が実行されている必要があります。 SQL ベースの属性ストアを使用するときは、接続文字列も構成する必要があります。

カスタム属性ストア

複雑なシナリオを実現するために、独自の属性ストアを開発することができます。 AD FS 内蔵のポリシー言語からカスタム属性ストアを参照できるので、次に示すようなシナリオの拡張が可能になります。

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

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

  • トークンを取得することをユーザーに許可する

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

カスタム属性ストアを使用するときは、接続文字列を構成することも必要になる可能性があります。 このような場合は、カスタム属性ストアへの接続を可能にするような、任意のカスタム コードを使用できます。 この場合の接続文字列は、一連の名前/値ペアであり、この文字列をどのように解釈するかはカスタム属性ストアの開発者が実装します。

カスタム属性ストアの開発と使用の方法の詳細については、「属性ストアの概要」を参照してください。

アプリケーションの要件

フェデレーション サーバーは、フェデレーション アプリケーションと通信してそのアプリケーションを保護することができます。フェデレーション アプリケーションの例としては、要求に対応するアプリケーションがあります。

認証の要件

AD FS は、既存の Windows 認証 (Kerberos 認証、NTLM、スマート カード、X.509 v3 クライアント側証明書など) と統合する機能を備えています。 フェデレーション サーバーは、標準の Kerberos 認証を使用して、ドメインに対するユーザーの認証を行います。 クライアントの認証に使用できるものとしては、フォームベースの認証、スマート カード認証、Windows 統合認証があり、認証をどのように構成するかによって決まります。

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

スマート カード ログオン

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

スマート カード認証

スマート カード認証では、Kerberos プロトコルを使用して、フェデレーション サーバーに対するアカウントの認証が行われます。 AD FS は、新しい認証方法を追加するように拡張することはできません。 スマート カードの中の証明書は、クライアント コンピューター上の信頼されたルートまでチェーンでつながっていなくてもかまいません。 スマート カード ベースの証明書を AD FS とともに使用するには、次の条件を満たしている必要があります。

  • ブラウザーが存在するコンピューター上でスマート カードのリーダーと暗号化サービス プロバイダー (CSP) が動作する必要があります。

  • スマート カード証明書は、アカウント フェデレーション サーバーとアカウント フェデレーション サーバー プロキシ上の信頼されたルートまでチェーンでつながっている必要があります。

  • 証明書は、AD DS 内のユーザー アカウントに、次のいずれかの方法でマッピングされている必要があります。

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

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

特定の認証強度が求められるシナリオをサポートするために、ユーザーがどのように認証されたかを示すクレームを作成するように AD FS を構成することも可能です。 証明書利用者は、このクレームを使用して権限付与に関する決定を行うことができます。

参照

Windows Server 2012 での AD FS 設計ガイド