Active Directory フェデレーション サービス (AD FS) を使用して組織間の (フェデレーション ベースの) コラボレーションを計画する場合は、まず、相手の組織がインターネット経由でアクセスする Web リソースをどちらの組織がホストするかを決定します。この決定は、AD FS の展開方法に影響を与えると共に、AD FS インフラストラクチャの計画の基礎になります。

AD FS のフェデレーション Web シングル サインオン (SSO) やフォレストの信頼を使用するフェデレーション Web SSO などのフェデレーション デザイン (Web SSO デザイン以外) では、"アカウント パートナー" および "リソース パートナー" という用語を使用して、アカウントをホストする組織 (アカウント パートナー) と Web ベースのリソースをホストする組織 (リソース パートナー) を区別します。"フェデレーションの信頼" とは、アカウント パートナーとリソース パートナー間に確立された一方向の非推移性の関係を表す、AD FS の用語です。

AD FS のデザインの詳細については、「フェデレーション デザインとは」を参照してください。

次の各セクションでは、アカウント パートナーとリソース パートナーに関連する概念をいくつか説明します。

アカウント パートナー

アカウント パートナーはフェデレーションの信頼関係にある組織を表し、ユーザー アカウントを Active Directory ドメイン サービス (AD DS) ストアまたは Active Directory ライトウェイト ディレクトリ サービス (AD LDS) ストアのいずれかに物理的に格納します。アカウント パートナーは、ユーザーの資格情報の収集と認証、そのユーザー用の要求の作成、およびセキュリティ トークンへの要求のパッケージを行います。このトークンをフェデレーションの信頼間で提示することにより、リソース パートナーの組織に配置されている Web ベースのリソースにアクセスすることができます。

つまり、アカウント パートナーは、アカウント側のフェデレーション サービスがセキュリティ トークンを発行する対象となるユーザーの組織を表します。アカウント パートナーの組織におけるフェデレーション サービスでは、ローカル ユーザーが認証され、リソース パートナーが承認の判断を行う際に使用するセキュリティ トークンが作成されます。

AD DS との関連では、AD FS におけるアカウント パートナーとは、物理的に別のフォレストにあるリソースへアクセスする必要のあるアカウントを持つ、単一の AD DS フォレストと概念的に同じものです。この例のフォレスト内にあるアカウントは、2 つのフォレスト間に外部の信頼関係またはフォレストの信頼関係が存在し、かつユーザーがアクセスしようとしているリソースに適切な承認アクセス許可が設定されていた場合にのみ、リソース フォレスト内のリソースにアクセスできます。

厳密に言えば、この類似性には、AD FS におけるアカウントの組織およびパートナーの組織の関係と、AD DS におけるアカウント フォレストおよびリソース フォレストの関係が、概念的に似ていることを強調する意味合いが含まれています。外部の信頼とフォレストの信頼では、AD FS が機能する必要はありません。

リソース パートナーに送る要求の作成

要求とは、サーバーが作成する、クライアントに関する説明 (名前、ID、キー、グループ、特権、機能など) です。アカウント パートナーは、リソース パートナーのフェデレーション サービスで使用される要求を作成します。次の一覧では、リソース フェデレーション サーバー側のアカウント パートナーで構成可能な要求の種類について説明します。

  • UPN 要求

    アカウント パートナーを構成するときに、アカウント パートナーから受け入れ可能なユーザー プリンシパル名 (UPN) のドメインおよびサフィックスの一覧を指定できます。ドメイン名が一覧にない UPN ID を受け取った場合、その要求は拒否されます。

  • 電子メール要求

    アカウント パートナーを構成するときに、アカウント パートナーから受け入れ可能な電子メールのドメインおよびサフィックスの一覧を指定できます。UPN 要求と同様に、ドメイン名が一覧にない電子メール ID が受信された場合は、その要求が拒否されます。

  • 共通名要求

    アカウント パートナーを構成するときに、アカウント パートナーから共通名要求を受信することが可能かどうかを指定できます。この種類の要求はマップされません。有効な場合は、そのまま渡されるだけです。

  • グループの要求

    アカウント パートナーを構成するときに、アカウント パートナーから受け入れ可能な入力方向のグループの要求のセットを指定できます。そして、可能性のある各入力方向のグループを 1 つの組織グループの要求に関連付けることができます。これによって、グループ マッピングが作成されることに注意してください。入力方向のグループがマッピングされていないことが検出された場合は、破棄されます。

  • カスタム要求

    アカウント パートナーを構成するときに、アカウント パートナーから受け入れ可能なカスタム要求の入力方向の名前のセットを指定できます。そして、可能性のある各入力方向の名前を 1 つの組織のカスタム要求にマップすることができます。これによって、名前マッピングが作成されることに注意してください。入力方向のカスタム要求がマッピングされていないことが検出された場合は、破棄されます。

リソース パートナー

リソース パートナーは、フェデレーションの信頼関係における 2 つ目の組織的なパートナーです。リソース パートナーは、1 つまたは複数の Web ベースのアプリケーション (リソース) をホストする AD FS が有効な Web サーバーが存在する組織です。リソース パートナーは、アカウント パートナーを信頼して、ユーザーを認証します。そのため、リソース パートナーは、アカウント パートナー内のユーザーから送信されるセキュリティ トークン内にパッケージされた要求を使用して、承認の判断を行います。

つまり、リソース パートナーは、リソース側のフェデレーション サービスによって保護された AD FS が有効な Web サーバーを所有する組織を表します。リソース パートナーにおけるフェデレーション サービスでは、アカウント パートナーによって作成されたセキュリティ トークンを使用して、リソース パートナー内に配置されている AD FS が有効な Web サーバーに対して承認の判断を行います。

リソース パートナーの組織内の AD FS が有効な Web サーバーを AD FS リソースとして機能させるためには、AD FS のコンポーネントである AD FS Web エージェントをインストールする必要があります。AD FS リソースとして機能する Web サーバーは、要求に対応するアプリケーションまたは Windows NT トークン ベースのアプリケーションをホストすることができます。

AD FS が有効な Web サーバー上でホストされているアプリケーションが Windows NT トークンベースのアプリケーションである場合は、リソース パートナーの組織内の AD DS フォレストに対してリソース アカウントが要求される場合があります。

AD DS との関連では、リソース パートナーは、物理的に別のフォレストに格納されているアカウントに対する外部の信頼関係またはフォレストの信頼関係を通じて使用可能なリソースを含む、単一のフォレストと概念的に同じものです。

厳密に言えば、この類似性には、AD FS におけるアカウントの組織およびパートナーの組織の関係と、AD DS におけるアカウント フォレストおよびリソース フォレストの関係が、概念的に似ていることを強調する意味合いが含まれています。外部の信頼とフォレストの信頼では、AD FS が機能する必要はありません。

アカウント パートナーから送信される要求の使用

リソース パートナーは、アカウント パートナーのフェデレーション サービスによって生成され、セキュリティ トークンにパッケージされた要求を使用します。次の一覧では、要求をリソース パートナーへ送信する方法ついて説明します。

  • UPN 要求

    リソース パートナーを構成するときに、リソース パートナーに UPN 要求を送信するかどうかを指定できます。指定された出力方向のサフィックスに任意のサフィックスがマップされるように、サフィックスのマッピングを指定することもできます。たとえば、julianp@sales.tailspintoys.com は julianp@tailspintoys.com にマップできます。出力方向のサフィックスは 1 つしか指定できないことに注意してください。

  • 電子メール要求

    リソース パートナーを構成するときに、リソース パートナーに電子メール要求を送信するかどうかを指定できます。指定されたサフィックスに任意のサフィックスがマップされるように、サフィックスのマッピングを指定することもできます。たとえば、vernettep@sales.tailspintoys.com は vernettep@tailspintoys.com にマップできます。出力方向のサフィックスは 1 つしか指定できないことに注意してください。

  • 共通名要求

    リソース パートナーを構成するときに、リソース パートナーに共通名要求を送信することが可能かどうかを指定できます。この種類の要求はマップされません。有効な場合は、そのままリソース パートナーに渡されるだけです。

  • グループの要求

    リソース パートナーを構成するときに、リソース パートナーが受け入れる出力方向のグループの要求のセットを指定できます。さらに、可能性のある各出力方向のグループの要求を組織グループの要求に関連付けることができます。これによって、グループ マッピングのセットが作成されることに注意してください。出力方向のグループの要求と一致しない組織グループの要求は作成されません。

  • カスタム要求

    リソース パートナーを構成するときに、リソース パートナーが受け入れる出力方向のカスタム要求のセットを指定できます。可能性のある各出力方向の組織カスタム要求を 1 つのカスタム要求にマップできます。これによって、名前マッピングのセットが作成されることに注意してください。出力方向のカスタム要求と一致しない組織のカスタム要求は作成されません。

強化された ID プライバシー

[強化された ID プライバシーを有効にする] は、信頼ポリシー内のリソース パートナーで構成可能なオプションの設定です。[強化された ID プライバシーを有効にする] オプションが有効な場合、この設定によって、出力方向の UPN 要求および電子メール要求のユーザー名の部分がハッシュされます。共通名は、ランダムな値に置き換えられます。

この機能の目的は、次のことを防止することです。

  • リソース パートナーが、ID 要求を、個人を特定できるユーザー情報に関連付けること。

  • パートナーどうしが共謀して、ID 要求を、個人を特定できるユーザー情報に関連付けること。このオプションを設定することにより、ID 要求値は信頼する側の領域のパートナーによって異なるが、パートナーごとではセッションを通して一貫したものになるように、パートナーごとに一意のハッシュが作成されます。

  • ハッシュへの単純な辞書攻撃。これは、信頼ポリシー内のデータ (リソース パートナーは知らないデータ) を使用してユーザー値を "ソルティング" する (データにランダムな値を混ぜる) ことによって回避されます。


目次