フェデレーション

  • [アーティクル]

製品: Exchange Server 2013

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

重要

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

主要な関連用語

次の一覧では、Exchange 2013 のフェデレーションに関連付けられているコア コンポーネントを定義します。

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

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

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

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

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

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

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

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

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

    • アカウント名前空間

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

    • 組織識別子 (OrgID)

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

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

  • 非フェデレーション organization: Microsoft Entra認証システムとのフェデレーション信頼が確立されていない組織。

  • organization識別子 (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は、Microsoft Entra認証システムで使用するためにorganizationがドメインを所有していることを証明するためにも使用されます。 これは、各フェデレーション ドメインのパブリック ドメイン ネーム システム (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 が必要です。