フェデレーション

製品: Exchange Server 2013

インフォメーション ワーカーは、外部の受信者、ベンダー、パートナー、および顧客との共同作業、および空き時間 (予定表の空き時間とも言う) 情報の共有を頻繁に行う必要があります。 Microsoft Exchange Server 2013 のフェデレーションは、このような共同作業の取り組みに役立ちます。 フェデレーションとは、ユーザーが他の外部のフェデレーション組織の受信者と予定表情報を共有するための簡単な方法であるフェデレーション共有をサポートする、基礎となる信頼インフラストラクチャを意味します。 フェデレーション共有の詳細については、「共有」を参照してください。

重要

Exchange Server 2013 のこの機能は、中国で 21Vianet によって運用される Office 365 との完全な互換性を備えておらず、いくつかの機能制限が適用される場合があります。 詳細については、21Vianet が運用する Office 365 を参照してください。

主要な関連用語

次の一覧に、Exchange 2013 のフェデレーションに関連するコア コンポーネントの定義を示します。

  • アプリケーション識別子 (AppID): Exchange 組織を識別するために Microsoft Entra 認証システムによって生成される一意の番号。 AppID は、Microsoft Entra 認証システムとのフェデレーション信頼を作成するときに自動的に生成されます。

  • 委任トークン: Microsoft Entra 認証システムによって発行されるセキュリティ アサーション マークアップ言語 (SAML) トークンで、あるフェデレーション organization のユーザーを別のフェデレーション organization から信頼できるようにします。 委任トークンには、ユーザーのメール アドレス、不変識別子、アクション用トークンが発行されたオファーに関連付けられている情報が含まれます。

  • 外部 Federated organization: Microsoft Entra 認証システムとのフェデレーション信頼を確立した外部 Exchange organization。

  • フェデレーション共有: Microsoft Entra 認証システムとのフェデレーション信頼を利用して、クロスプレミスの Exchange 展開を含む Exchange 組織全体で機能する一連の Exchange 機能。 さらに、これらの機能は、複数の Exchange 組織にわたってユーザーの代わりに、サーバー間の認証済みの要求を作成するために使用されます。

  • フェデレーション ドメイン: Exchange organization の組織識別子 (OrgID) に追加される承認された権限のあるドメイン organization。

  • ドメイン証明暗号化文字列: Microsoft Entra 認証システムで使用されるドメインを organization が所有していることを証明するために Exchange organization によって使用される、暗号化で保護された文字列。 文字列は、 [フェデレーションの信頼を有効にする] ウィザードを使用して自動生成するか、 Get-FederatedDomainProof コマンドレットを使用して生成できます。

  • フェデレーション共有ポリシー: ユーザーが確立した予定表情報の個人間の共有を有効および制御するorganizationレベルのポリシー。

  • フェデレーション: 共通の目的を達成するための 2 つの Exchange 組織間の信頼ベースの契約。 フェデレーションでは、両方の組織が、互いに相手の組織による認証アサーションの認識を必要とします。

  • フェデレーションの信頼: Exchange organization の次のコンポーネントを定義する Microsoft Entra 認証システムとの関係:

    • アカウント名前空間

    • アプリケーション識別子 (AppID)

    • 組織識別子 (OrgID)

    • フェデレーション ドメイン

    他のフェデレーション Exchange 組織とのフェデレーション共有を構成するには、Microsoft Entra 認証システムを使用してフェデレーション信頼を確立する必要があります。

  • non-federated organization: Microsoft Entra 認証システムで確立されたフェデレーションの信頼関係がない組織。

  • organization identifier (OrgID): organization で構成されている権限のある承認済みドメインのうち、フェデレーションに対して有効になっているかどうかを定義します。 OrgID に構成されているフェデレーション ドメインを持つ電子メール アドレスを持つ受信者のみが Microsoft Entra 認証システムによって認識され、フェデレーション共有機能を使用できます。 OrgID は、定義済みの文字列と、 [フェデレーションの信頼を有効にする] ウィザードでフェデレーション用に選択された最初の承認済みドメインの組み合わせです。 たとえば、フェデレーション ドメイン contoso.com を組織のプライマリ SMTP ドメインとして指定すると、アカウントの名前空間 FYDIBOHF25SPDLT.contoso.com がフェデレーション信頼の OrgID として自動的に作成されます。

  • organization 関係: 受信者が空き時間情報 (予定表の空き時間情報) を共有できる 2 つのフェデレーション Exchange 組織間の 1 対 1 の関係。 organization 関係には Microsoft Entra 認証システムとのフェデレーション信頼が必要であり、Exchange 組織間で Active Directory フォレストまたはドメイン信頼を使用する必要性を置き換えます。

  • Microsoft Entra 認証システム: フェデレーションされた Microsoft Exchange 組織間の信頼ブローカーとして機能する無料のクラウドベースの ID サービス。 このゲートウェイは、Exchange 受信者から他の Exchange フェデレーション組織の受信者の情報を要求されたときに、委任トークンを要求した受信者に発行します。 詳細については、「Microsoft Entra ID」を参照してください。

Microsoft Entra 認証システム

Microsoft が提供する無料のクラウドベースのサービスである Microsoft Entra 認証システムは、オンプレミスの Exchange 2013 organizationと他のフェデレーションされた Exchange 2010 および Exchange 2013 組織の間の信頼ブローカーとして機能します。 Exchange organization でフェデレーションを構成する場合は、Microsoft Entra 認証システムとの 1 回限りのフェデレーション信頼を確立して、organization のフェデレーション パートナーになる必要があります。 この信頼が確立されると、Active Directory (ID プロバイダーと呼ばれます) によって認証されたユーザーには、Microsoft Entra 認証システムによってセキュリティ アサーション マークアップ言語 (SAML) 委任トークンが発行されます。 これらの委任トークンによって、特定のフェデレーション Exchange 組織のユーザーは、別のフェデレーション Exchange 組織によって信頼されるようになります。 Microsoft Entra 認証システムが信頼ブローカーとして機能するため、組織は他の組織と複数の個別の信頼関係を確立する必要がなく、ユーザーはシングル サインオン (SSO) エクスペリエンスを使用して外部リソースにアクセスできます。 詳細については、「Microsoft Entra ID」を参照してください。

フェデレーション信頼

Exchange 2013 フェデレーション共有機能を使用するには、Exchange 2013 organizationと Microsoft Entra 認証システムとの間にフェデレーション信頼を確立する必要があります。 Microsoft Entra 認証システムとのフェデレーション信頼を確立すると、organization のデジタル セキュリティ証明書と Microsoft Entra 認証システムが交換され、Microsoft Entra 認証システムの証明書とフェデレーション メタデータが取得されます。 フェデレーションの信頼を確立するには、Exchange 管理センター (EAC) の [フェデレーションの信頼を有効にする ] ウィザードを使用するか、Exchange 管理シェルの New-FederationTrust コマンドレットを使用します。 自己署名証明書は、[フェデレーションの信頼の有効化] ウィザードによって自動的に作成され、外部のフェデレーション組織からユーザーを信頼できるようにする Microsoft Entra 認証システムからの委任トークンに署名および暗号化するために使用されます。 証明書の要件の詳細については、このトピックで後述する「フェデレーションの証明書の要件」を参照してください。

Microsoft Entra 認証システムを使用してフェデレーション信頼を作成すると、Exchange organization 用にアプリケーション識別子 (AppID) が自動的に生成され、Get-FederationTrust コマンドレットの出力に表示されます。 AppID は、Exchange organization を一意に識別するために Microsoft Entra 認証システムによって使用されます。 また、Exchange organization によって使用され、organization が Microsoft Entra 認証システムで使用するドメインを所有していることを証明するためにも使用されます。 これは、各フェデレーション ドメインのパブリック ドメイン ネーム システム (DNS) ゾーンにテキスト (TXT) レコードを作成することによって行われます。

フェデレーション組織識別子

フェデレーション組織識別子 (OrgID) は、組織内で構成された権限のある承認済みドメインの中で、どのドメインがフェデレーションを使用可能であるかを定義します。 OrgID で構成された承認済みドメインを持つ電子メール アドレスを持つ受信者のみが Microsoft Entra 認証システムによって認識され、フェデレーション共有機能を使用できます。 新しいフェデレーション信頼を作成すると、Microsoft Entra 認証システムを使用して OrgID が自動的に作成されます。 この OrgID は、定義済みの文字列と、ウィザードでプライマリ共有ドメインとして選択された承認済みドメインの組み合わせです。 たとえば、共有有効ドメインの編集ウィザードで、フェデレーション ドメイン contoso.com を組織のプライマリ共有ドメインとして指定した場合、Exchange 組織のフェデレーション信頼の OrgID として FYDIBOHF25SPDLT.contoso.com アカウントの名前空間が自動的に作成されます。

Exchange 組織のプライマリ SMTP ドメインであっても、このドメインを Exchange 組織で承認済みのドメインとする必要はなく、ドメイン ネーム システム (DNS) の所有権の証明のための TXT レコードは必要ありません。 唯一の要件は、フェデレーション対象として選択した承認済みドメインは、最長で 32 文字に制限されるということです。 このサブドメインの唯一の目的は、Microsoft Entra 認証システムのフェデレーションされた名前空間として機能し、SAML 委任トークンを要求する受信者の一意の識別子を維持することです。 SAML トークンの詳細については、「SAML トークンとクレーム」を参照してください。

承認されたドメインは、いつでもフェデレーション信頼に追加または削除できます。 組織内ですべてのフェデレーション共有機能を有効または無効にするには、フェデレーション信頼の OrgID を有効または無効にするだけで済みます。

重要

フェデレーション信頼で使用する OrgID、承認済みドメイン、または AppID を変更すると、組織内のすべてのフェデレーションの共有機能に影響します。 また、このような変更は、Exchange Online およびハイブリッド展開の構成などの外部のフェデレーション Exchange 組織にも影響します。 これらのフェデレーション信頼構成の設定に対して変更を行った場合は、すべての外部フェデレーション パートナーに通知することをお勧めします。

フェデレーションの例

Contoso, Ltd. と Fabrikam, Inc. の 2 つの Exchange 組織では、ユーザーが予定表の空き時間情報を相互に共有できるようにしたいと考えています。 各 organization は、Microsoft Entra 認証システムとのフェデレーション信頼を作成し、ユーザーの電子メール アドレス ドメインに使用されるドメインを含めるようにアカウントの名前空間を構成します。

Contoso の従業員は、contoso.com、contoso.co.uk、contoso.ca のいずれかの電子メール アドレス ドメインを使用します。 Fabrikam の従業員は、fabrikam.com、fabrikam.org、fabrikam.net のいずれかの電子メール アドレス ドメインを使用します。 どちらの組織でも、承認されたすべての電子メール ドメインが、Microsoft Entra 認証システムとのフェデレーション信頼のアカウント名前空間に含まれていることを確認します。 2 つの組織間で複雑な Active Directory フォレストまたはドメイン信頼構成を必要とはせずに、両方の組織が互いの組織の関係を構成して、予定表の空き時間情報の共有を可能にします。

次の図は、Contoso, Ltd. と Fabrikam, Inc. の間のフェデレーション構成を示します。

フェデレーションの共有例

フェデレーション信頼とフェデレーション共有。

フェデレーションのための証明書の要件

Microsoft Entra 認証システムとのフェデレーションの信頼を確立するには、自己署名証明書または証明機関 (CA) によって署名された X.509 証明書を作成して、信頼の作成に使用する Exchange 2013 サーバーにインストールする必要があります。 自己署名証明書を使用することを強くお勧めします。この証明書は、EAC の フェデレーション信頼の有効化ウィ ザードを使用して自動的に作成およびインストールされます。 この証明書は、フェデレーション共有に使用される委任トークンの署名と暗号化にのみ使用され、フェデレーションの信頼に必要な証明書は 1 つだけです。 Exchange 2013 は、organization 内の他のすべての Exchange 2013 サーバーに証明書を自動的に配布します。

外部 CA によって署名された X.509 証明書を使用する場合は、証明書が以下の要件を満たしている必要があります。

  • 信頼された CA: 可能であれば、Windows Live で信頼されている CA から X.509 Secure Sockets Layer (SSL) 証明書を発行する必要があります。 現在、Microsoft が認定していない証明機関が発行した証明書も使用できます。 信頼済み証明機関の一覧については、「 フェデレーション信頼のための信頼されたルート証明機関」を参照してください。

  • サブジェクト キー識別子: 証明書にはサブジェクト キー識別子フィールドが必要です。 商用 CA によって発行された X.509 証明書のほとんどには、この識別子が含まれています。

  • CryptoAPI 暗号化サービス プロバイダー (CSP): 証明書では CryptoAPI CSP を使用する必要があります。 Cryptography API:Next Generation (CNG) プロバイダーを使用する証明書は、フェデレーションではサポートされません。 Exchange を使用して証明書要求を作成する場合は、CryptoAPI プロバイダーを使用します。 詳細については、「 Cryptography API:Next Generation」を参照してください (このサイトは英語の場合があります)。

  • RSA 署名アルゴリズム: 証明書では、署名アルゴリズムとして RSA を使用する必要があります。

  • エクスポート可能な秘密キー: 証明書の生成に使用する秘密キーはエクスポート可能である必要があります。 EAC で [Exchange 証明書の新規作成] ウィザードを使用するか、シェルで New-ExchangeCertificate コマンドレットを実行することで証明書要求を作成する場合に、秘密キーをエクスポート可能に指定します。

  • 現在の証明書: 証明書は最新である必要があります。 有効期限が切れた証明書や失効した証明書を使用して、フェデレーション信頼を作成することはできません。

  • 拡張キー使用法: 証明書には、拡張キー使用法 (EKU) の種類である クライアント認証 (1.3.6.1.5.5.7.3.2) が含まれている必要があります。 この使用法タイプは、リモート コンピューターに自分の ID を提供するために使用されます。 EAC またはシェルを使用して証明書要求を生成する場合に、既定でこの使用法タイプが含まれます。

注:

認証のために証明書が使用されることがないため、証明書にはサブジェクト名やサブジェクトの別名についての要件はありません。 ホスト名、ドメイン名、または他の何らかの名前と同じサブジェクト名を持つ証明書を使用することができます。

新しい証明書への切り替え

フェデレーション信頼を作成するために使用する証明書は、現在の証明書として指定されます。 ただし、定期的にフェデレーション信頼の新しい証明書をインストールして使用しなければならない場合があります。 たとえば、現在の証明書の期限が切れた場合、組織のビジネスやセキュリティの要件を満たす必要がある場合などに、新しい証明書を使用する必要があります。 新しい証明書への移行をシームレスに実行するには、Exchange 2013 サーバー上に新しい証明書をインストールし、その証明書を新しい証明書として指定するようにフェデレーション信頼を構成する必要があります。 Exchange 2013 によって、新しい証明書は組織内の他のすべての Exchange 2013 サーバーに自動的に配布されます。 Active Directory トポロジによっては、証明書の配布に時間がかかる場合があります。 シェルで Test-FederationTrustCertificate コマンドレットを使用すると、証明書の状態を確認できます。

証明書の配布状態を確認したら、新しい証明書を使用するように信頼を構成します。 証明書の切り替えを実行すると、現在の証明書は以前の証明書として指定され、新しい証明書が現在の証明書として指定されます。 新しい証明書は Microsoft Entra 認証システムに公開され、Microsoft Entra 認証システムと交換されるすべての新しいトークンは新しい証明書を使用して暗号化されます。

注:

この証明書の切り替え処理は、フェデレーションによってのみ使用されます。 証明書を必要とする Exchange 2013 の他の機能に同じ証明書を使用する場合は、新しい証明書の入手、インストール、および移行を計画する際にその機能の要件を考慮する必要があります。

フェデレーションのファイアウォールの検討事項

フェデレーション機能は、組織内のメールボックスおよびクライアント アクセス サーバーによる HTTPS を使用したインターネットへの送信アクセスを必要とします。 組織内のすべての Exchange 2013 メールボックスおよびクライアント アクセス サーバーからの送信 HTTPS アクセス (TCP ポート 443) を許可する必要があります。

外部組織が組織の空き時間情報にアクセスするには、クライアント アクセス サーバーをインターネットに公開する必要があります。 これには、インターネットからクライアント アクセス サーバーへの受信 HTTPS アクセスが必要です。 クライアント アクセス サーバーをインターネットに公開していない Active Directory サイトのクライアント アクセス サーバーは、インターネットからアクセスできるその他の Active Directory サイトのクライアント アクセス サーバーを使用できます。 インターネットに公開されていないクライアント アクセス サーバーは、外部組織から可視の URL で設定された Web サービス仮想ディレクトリの外部 URL が必要です。

  • Last updated on