フェデレーションFederation

製品: Exchange Server 2013Applies to: Exchange Server 2013

インフォメーション ワーカーは、外部の受信者、ベンダー、パートナー、および顧客との共同作業、および空き時間 (予定表の空き時間とも言う) 情報の共有を頻繁に行う必要があります。Information workers frequently need to collaborate with external recipients, vendors, partners, and customers and share their free/busy (also known as calendar availability) information. Microsoft Exchange Server 2013 のフェデレーションは、このような共同作業の取り組みに役立ちます。Federation in Microsoft Exchange Server 2013 helps with these collaboration efforts. フェデレーションとは、ユーザーが他の外部のフェデレーション組織の受信者と予定表情報を共有するための簡単な方法であるフェデレーション共有をサポートする、基礎となる信頼インフラストラクチャを意味します。Federation refers to the underlying trust infrastructure that supports federated sharing, an easy method for users to share calendar information with recipients in other external federated organizations. フェデレーション共有の詳細については、「共有」を参照してください。To learn more about federated sharing, see Sharing.

重要

Exchange Server 2013 のこの機能は、中国で 21Vianet によって運用される Office 365 との完全な互換性を備えておらず、いくつかの機能制限が適用される場合があります。詳細については、「21Vianet が運用している Office 365 について」を参照してください。This feature of Exchange Server 2013 isn't fully compatible with Office 365 operated by 21Vianet in China and some feature limitations may apply. For more information, see Learn about Office 365 operated by 21Vianet.

主要な関連用語Key terminology

次の一覧は、Exchange 2013 のフェデレーションに関連付けられているコアコンポーネントを定義しています。The following list defines the core components associated with federation in Exchange 2013.

  • アプリケーション識別子 (AppID): Exchange 組織を識別するために Azure Active Directory 認証システムによって生成された一意の番号。application identifier (AppID): A unique number generated by the Azure Active Directory authentication system to identify Exchange organizations. AppID は、Azure Active Directory 認証システムでフェデレーション信頼を作成するときに自動生成されます。The AppID is automatically generated when you create a federation trust with the Azure Active Directory authentication system.

  • 委任トークン: あるフェデレーション組織のユーザーが別のフェデレーション組織によって信頼されるようにする、Azure Active Directory 認証システムによって発行されるセキュリティアサートマークアップ言語 (SAML) トークン。delegation token: A Security Assertion Markup Language (SAML) token issued by the Azure Active Directory authentication system that allows users from one federated organization to be trusted by another federated organization. 委任トークンには、ユーザーの電子メールアドレス、不変識別子、およびアクションのためにトークンが発行されたサービスに関連付けられている情報が含まれています。A delegation token contains the user's email address, an immutable identifier, and information associated with the offer for which the token is issued for action.

  • 外部フェデレーション組織: Azure Active Directory 認証システムとのフェデレーション信頼が確立されている外部 Exchange 組織。external federated organization: An external Exchange organization that's established a federation trust with the Azure Active Directory authentication system.

  • フェデレーション共有: Azure Active Directory 認証システムとのフェデレーション信頼を活用して、クロスプレミスの exchange 展開を含む exchange 組織間で機能する exchange 機能のグループ。federated sharing: A group of Exchange features that leverage a federation trust with the Azure Active Directory authentication system to work across Exchange organizations, including cross-premises Exchange deployments. さらに、これらの機能は、複数の Exchange 組織にわたってユーザーの代わりに、サーバー間の認証済みの要求を作成するために使用されます。Together, these features are used to make authenticated requests between servers on behalf of users across multiple Exchange organizations.

  • [フェデレーションドメイン]: Exchange 組織の組織識別子 (orgid) に追加される、権限のある承認済みドメイン。federated domain: An accepted authoritative domain that's added to the organization identifier (OrgID) for an Exchange organization.

  • ドメイン証明の暗号化文字列: Exchange 組織が、Azure Active Directory 認証システムで使用されているドメインを所有していることを証明するために使用する、暗号で保護された文字列。domain proof encryption string: A cryptographically secure string used by an Exchange organization to provide proof that the organization owns the domain used with the Azure Active Directory authentication system. 文字列は、 [フェデレーションの信頼を有効にする] ウィザードを使用して自動生成するか、 Get-FederatedDomainProof コマンドレットを使用して生成できます。The string is generated automatically when using the Enable federation trust wizard or can be generated by using the Get-FederatedDomainProof cmdlet.

  • フェデレーション共有ポリシー: ユーザーによって設定される、予定表情報の個人間共有を可能にし、制御する組織レベルのポリシー。federated sharing policy: An organization-level policy that enables and controls user-established, person-to-person sharing of calendar information.

  • フェデレーション: 共通の目的を実現するための2つの Exchange 組織間の信頼ベースの合意。federation: A trust-based agreement between two Exchange organizations to achieve a common purpose. フェデレーションでは、両方の組織が、互いに相手の組織による認証アサーションの認識を必要とします。With federation, both organizations want authentication assertions from one organization to be recognized by the other.

  • フェデレーション信頼: Exchange 組織の次のコンポーネントを定義する Azure Active Directory 認証システムとの関係。federation trust: A relationship with the Azure Active Directory authentication system that defines the following components for your Exchange organization:

    • アカウント名前空間Account namespace

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

    • 組織識別子 (OrgID)Organization identifier (OrgID)

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

    他の Exchange フェデレーション組織とのフェデレーション共有を構成するには、Azure Active Directory 認証システムでフェデレーション信頼を確立する必要があります。To configure federated sharing with other federated Exchange organizations, a federation trust must be established with the Azure Active Directory authentication system.

  • フェデレーション外の組織: Azure Active Directory 認証システムとのフェデレーション信頼が確立されていない組織。non-federated organization: Organizations that don't have a federation trust established with the Azure Active Directory authentication system.

  • organization identifier (orgid): 組織内で構成されている権限のある承認済みドメインのうち、フェデレーションに対して有効になっているものを定義します。organization identifier (OrgID): Defines which of the authoritative accepted domains configured in an organization are enabled for federation. 電子メール アドレスに OrgID で構成されたフェデレーション ドメインが含まれる受信者のみが、Azure Active Directory 認証システムによって認識され、フェデレーション共有の機能を使用できます。Only recipients that have e-mail addresses with federated domains configured in the OrgID are recognized by the Azure Active Directory authentication system and are able to use federated sharing features. OrgID は、定義済みの文字列と、 [フェデレーションの信頼を有効にする] ウィザードでフェデレーション用に選択された最初の承認済みドメインの組み合わせです。The OrgID is a combination of a pre-defined string and the first accepted domain selected for federation in the Enable federation trust wizard. たとえば、フェデレーション ドメイン contoso.com を組織のプライマリ SMTP ドメインとして指定すると、アカウントの名前空間 FYDIBOHF25SPDLT.contoso.com がフェデレーション信頼の OrgID として自動的に作成されます。For example, if you specify the federated domain contoso.com as your organization's primary SMTP domain, the account namespace FYDIBOHF25SPDLT.contoso.com will be automatically created as the OrgID for the federation trust.

  • 組織上の関係: 受信者が空き時間 (予定表の空き時間) 情報を共有できるようにする、2つのフェデレーションされた Exchange 組織間の1対1の関係。organization relationship: A one-to-one relationship between two federated Exchange organizations that allows recipients to share free/busy (calendar availability) information. 組織の関係では、Azure Active Directory 認証システムとのフェデレーション信頼が必要となり、Exchange 組織間で Active Directory のフォレストまたはドメインの信頼を使用する必要がなくなります。An organization relationship requires a federation trust with the Azure Active Directory authentication system and replaces the need to use Active Directory forest or domain trusts between Exchange organizations.

  • Azure Active Directory 認証システム: フェデレーション Microsoft Exchange 組織間の信頼ブローカーとして機能する、無料のクラウドベースの id サービス。Azure Active Directory authentication system: A free, cloud-based identity service that acts as the trust broker between federated Microsoft Exchange organizations. このゲートウェイは、Exchange 受信者から他の Exchange フェデレーション組織の受信者の情報を要求されたときに、委任トークンを要求した受信者に発行します。It's responsible for issuing delegation tokens to Exchange recipients when they request information from recipients in other federated Exchange organizations. 詳細については、「Azure Active Directory」を参照してください。To learn more, see Azure Active Directory.

Azure AD 認証システムAzure AD authentication system

Microsoft が提供する無料のクラウドベース サービスである Azure Active Directory 認証システムは、オンプレミスの Exchange 2013 組織と、その他のフェデレーション Exchange 2010 組織および Exchange 2013 組織の間で信頼ブローカーとして機能します。The Azure Active Directory authentication system, a free cloud-based service offered by Microsoft, acts as the trust broker between your on-premises Exchange 2013 organization and other federated Exchange 2010 and Exchange 2013 organizations. Exchange 組織でフェデレーションを構成するには、 認証システムとのワンタイム フェデレーション信頼を確立し、Azure Active Directory 認証システムがその組織のフェデレーション パートナーになれるようにする必要があります。If you want to configure federation in your Exchange organization, you must establish a one-time federation trust with the Azure Active Directory authentication system, so that it can become a federation partner with your organization. この信頼が確立されている場合、Active Directory ( id プロバイダーと呼ばれる) によって認証されたユーザーには、Azure AD 認証システムによって Security Assertion Markup LANGUAGE (SAML) 委任トークンが発行されます。With this trust in place, users authenticated by Active Directory (known as identity providers) are issued Security Assertion Markup Language (SAML) delegation tokens by the Azure AD authentication system. これらの委任トークンによって、特定のフェデレーション Exchange 組織のユーザーは、別のフェデレーション Exchange 組織によって信頼されるようになります。These delegation tokens allow users from one federated Exchange organization to be trusted by another federated Exchange organization. 信頼ブローカーとして機能する Azure AD 認証システムを使用することで、組織は他の組織と複数の信頼関係を個別に確立する必要がなくなり、ユーザーはシングル サインオン (SSO) 操作によって外部のリソースにアクセスできます。With the Azure AD authentication system acting as the trust broker, organizations aren't required to establish multiple individual trust relationships with other organizations, and users can access external resources using a single sign-on (SSO) experience. 詳細については、「Azure Active Directory」を参照してください。For more information, see Azure Active Directory.

フェデレーション信頼Federation trust

Exchange 2013 のフェデレーション共有機能を使用するには、Exchange 2013 組織と Azure AD 認証システムの間でフェデレーションの信頼を確立する必要があります。To use Exchange 2013 federated sharing features, you must establish a federation trust between your Exchange 2013 organization and the Azure AD authentication system. Azure AD 認証システムとのフェデレーション信頼を確立すると、組織のデジタル セキュリティ証明書が Azure AD 認証システムに置き換えられ、Azure AD 認証システムの証明書とフェデレーション メタデータが取得されます。Establishing a federation trust with the Azure AD authentication system exchanges your organization's digital security certificate with the Azure AD authentication system and retrieves the Azure AD authentication system certificate and federation metadata. フェデレーション信頼を確立するには、Exchange 管理センター (EAC) または Exchange 管理シェルのget-federationtrustコマンドレットで [フェデレーションの信頼を有効にする] ウィザードを使用します。You can establish a federation trust by using the Enable federation trust wizard in the Exchange admin center (EAC) or the New-FederationTrust cmdlet in the Exchange Management Shell. 自己署名証明書が [フェデレーションの信頼を有効にする] ウィザードによって自動的に作成され、ユーザーが外部のフェデレーション組織によって信頼されるようにする Azure AD 認証システムからの委任トークンを署名および暗号化するために使用されます。A self-signed certificate is automatically created by the Enable federation trust wizard and is used for signing and encrypting delegation tokens from the Azure AD authentication system that allow users to be trusted by external federated organizations. 証明書の要件の詳細については、このトピックで後述する「フェデレーションの証明書要件」を参照してください。For details about certificate requirements, see Certificate Requirements for Federation later in this topic.

Azure AD 認証システムとのフェデレーション信頼を作成すると、Exchange 組織のアプリケーション識別子(AppID) が自動的に生成され、get-federationtrust コマンドレットの出力に表示されます。When you create a federation trust with the Azure AD authentication system, an application identifier (AppID) is automatically generated for your Exchange organization and provided in the output of the Get-FederationTrust cmdlet. AppID は、Azure AD 認証システムが Exchange 組織を一意に識別するために使用されます。The AppID is used by the Azure AD authentication system to uniquely identify your Exchange organization. また、Exchange 組織によって、Azure AD 認証システムで使用するドメインを組織が所有していることを証明するためにも使用されます。It's also used by the Exchange organization to provide proof that your organization owns the domain for use with the Azure AD authentication system. これは、各フェデレーション ドメインのパブリック ドメイン ネーム システム (DNS) ゾーンにテキスト (TXT) レコードを作成することによって行われます。This is done by creating a text (TXT) record in the public Domain Name System (DNS) zone for each federated domain.

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

フェデレーション組織識別子 (OrgID) は、組織内で構成された権限のある承認済みドメインの中で、どのドメインがフェデレーションを使用可能であるかを定義します。The federated organization identifier (OrgID) defines which of the authoritative accepted domains configured in your organization are enabled for federation. 電子メール アドレスに OrgID で構成された承認済みドメインが含まれる受信者のみが、Azure AD 認証システムによって認識され、フェデレーション共有の機能を使用できます。Only recipients that have e-mail addresses with accepted domains configured in the OrgID are recognized by the Azure AD authentication system and are able to use federated sharing features. フェデレーション信頼を新規作成すると、OrgID が Azure AD 認証システムで自動的に作成されます。When you create a new federation trust, an OrgID is automatically created with the Azure AD authentication system. この OrgID は、定義済みの文字列と、ウィザードでプライマリ共有ドメインとして選択された承認済みドメインの組み合わせです。This OrgID is a combination of a pre-defined string and the accepted domain selected as the primary shared domain in the wizard. たとえば、共有有効ドメインの編集ウィザードで、フェデレーション ドメイン contoso.com を組織のプライマリ共有ドメインとして指定した場合、Exchange 組織のフェデレーション信頼の OrgID として FYDIBOHF25SPDLT.contoso.com アカウントの名前空間が自動的に作成されます。For example, in the Edit Sharing-Enabled Domains wizard, if you specify the federated domain contoso.com as the primary shared domain in your organization, the FYDIBOHF25SPDLT.contoso.com account namespace will be automatically created as the OrgID for the federation trust for your Exchange organization.

Exchange 組織のプライマリ SMTP ドメインであっても、このドメインを Exchange 組織で承認済みのドメインとする必要はなく、ドメイン ネーム システム (DNS) の所有権の証明のための TXT レコードは必要ありません。唯一の要件は、フェデレーション対象として選択した承認済みドメインは、最長で 32 文字に制限されるということです。このサブドメインの唯一の目的は、Azure AD 認証システム用のフェデレーション名前空間として機能し、SAML 委任トークンを要求する受信者の一意の識別子を維持することです。SAML トークンの詳細については、「SAML トークンとクレーム」を参照してください。Although typically the primary SMTP domain for the Exchange organization, this domain doesn't have to be an accepted domain in your Exchange organization and doesn't require a domain name system (DNS) proof of ownership TXT record. The only requirement is that accepted domains selected to be federated are limited to a maximum of 32 characters. The only purpose of this subdomain is to serve as the federated namespace for the Azure AD authentication system to maintain unique identifiers for recipients that request SAML delegation tokens. For more information about SAML tokens, see SAML Tokens and Claims

承認されたドメインは、いつでもフェデレーション信頼に追加または削除できます。組織内ですべてのフェデレーション共有機能を有効または無効にするには、フェデレーション信頼の OrgID を有効または無効にするだけで済みます。You can add or remove accepted domains from the federation trust at any time. If you want to enable or disable all federation sharing features in your organization, all you have to do is enable or disable the OrgID for the federation trust.

重要

フェデレーション信頼で使用する OrgID、承認済みドメイン、または AppID を変更すると、組織内のすべてのフェデレーションの共有機能に影響します。また、このような変更は、Exchange Online およびハイブリッド展開の構成などの外部のフェデレーション Exchange 組織にも影響します。これらのフェデレーション信頼構成の設定に対して変更を行った場合は、すべての外部フェデレーション パートナーに通知することをお勧めします。If you change the OrgID, accepted domains, or the AppID used for the federation trust, all federation sharing features are affected in your organization. This also affects any external federated Exchange organizations, including Exchange Online and hybrid deployment configurations. We recommend that you notify all external federated partners of any changes to these federation trust configuration settings.

フェデレーションの例Federation example

Contoso, Ltd. と Fabrikam, Inc. という 2 つの Exchange 組織では、ユーザーが互いに予定表の空き時間情報を共有できるようにしようとしています。それぞれの組織で Azure AD 認証システムとのフェデレーション信頼を作成し、そのアカウント名前空間を、ユーザーの電子メール アドレス ドメインに使用するドメインを含むように構成します。Two Exchange organizations, Contoso, Ltd. and Fabrikam, Inc., want their users to be able to share calendar free/busy information with each other. Each organization creates a federation trust with the Azure AD authentication system and configures its account namespace to include the domain used for its user's e-mail address domain.

Contoso の従業員は、contoso.com、contoso.co.uk、contoso.ca のいずれかの電子メール アドレス ドメインを使用します。Fabrikam の従業員は、fabrikam.com、fabrikam.org、fabrikam.net のいずれかの電子メール アドレス ドメインを使用します。いずれの組織も、それぞれの Azure AD 認証システムとのフェデレーション信頼のアカウント名前空間に、すべての承認済み電子メール ドメインを含めるようにします。2 つの組織間で複雑な Active Directory フォレストまたはドメイン信頼構成を必要とはせずに、両方の組織が互いの組織の関係を構成して、予定表の空き時間情報の共有を可能にします。Contoso employees use one of the following e-mail address domains: contoso.com, contoso.co.uk, or contoso.ca. Fabrikam employees use one of the following e-mail address domains: fabrikam.com, fabrikam.org, or fabrikam.net. Both organizations make sure that all accepted e-mail domains are included in the account namespace for their federation trust with the Azure AD authentication system. Rather than requiring a complex Active Directory forest or domain trust configuration between the two organizations, both organizations configure an organization relationship with each other to enable calendar free/busy sharing.

次の図は、Contoso, Ltd. と Fabrikam, Inc. の間のフェデレーション構成を示します。The following figure illustrates the federation configuration between Contoso, Ltd. and Fabrikam, Inc.

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

フェデレーションの信頼とフェデレーションの共有Federation Trusts and Federated Sharing

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

Azure AD 認証システムとのフェデレーション信頼を確立するには、自己署名証明書、または証明機関 (CA) によって署名された X.509 証明書を作成し、信頼の作成に使用する Exchange 2013 サーバーにインストールする必要があります。EAC で [フェデレーションの信頼を有効にする] ウィザードを使用して自動的に作成およびインストールできる、自己署名証明書の使用を強くお勧めします。この証明書は、フェデレーションの共有に使用される委任トークンの署名および暗号化のみに使用されます。フェデレーション信頼に必要な証明書は 1 つだけです。この証明書は、Exchange 2013 によって組織内の他のすべての Exchange 2013 サーバーに自動的に配布されます。To establish a federation trust with the Azure AD authentication system, either a self-signed certificate or an X.509 certificate signed by a certification authority (CA) must be created and installed on the Exchange 2013 server used to create the trust. We strongly recommend using a self-signed certificate, which is automatically created and installed using the Enable federation trust wizard in the EAC. This certificate is used only to sign and encrypt delegation tokens used for federated sharing and only one certificate is required for the federation trust. Exchange 2013 automatically distributes the certificate to all other Exchange 2013 servers in the organization.

外部 CA によって署名された X.509 証明書を使用する場合は、証明書が以下の要件を満たしている必要があります。If you want to use an X.509 certificate signed by an external CA, the certificate must meet the following requirements:

  • 信頼された CA: 可能であれば、X.509 Secure Sockets LAYER (SSL) 証明書は Windows Live によって信頼された CA から発行される必要があります。Trusted CA: If possible, the X.509 Secure Sockets Layer (SSL) certificate should be issued from a CA trusted by Windows Live. 現在、Microsoft が認定していない証明機関が発行した証明書も使用できます。However, you can use certificates issued by CAs that aren't currently certified by Microsoft. 信頼済み証明機関の一覧については、「 フェデレーション信頼のための信頼されたルート証明機関」を参照してください。For a current list of trusted CAs, see Trusted root certification authorities for federation trusts.

  • サブジェクトキー識別子: 証明書にはサブジェクトキー識別子フィールドが必要です。Subject key identifier: The certificate must have a subject key identifier field. 商用 CA によって発行された X.509 証明書のほとんどには、この識別子が含まれています。Most X.509 certificates issued by commercial CAs have this identifier.

  • Cryptoapi 暗号化サービスプロバイダー (CSP): 証明書は CryptoAPI CSP を使用する必要があります。CryptoAPI cryptographic service provider (CSP): The certificate must use a CryptoAPI CSP. Cryptography API:Next Generation (CNG) プロバイダーを使用する証明書は、フェデレーションではサポートされません。Certificates that use Cryptography API: Next Generation (CNG) providers aren't supported for federation. Exchange を使用して証明書要求を作成する場合は、CryptoAPI プロバイダーを使用します。If you use Exchange to create a certificate request, a CryptoAPI provider is used. 詳細については、「 Cryptography API:Next Generation」を参照してください (このサイトは英語の場合があります)。For more information, see Cryptography API: Next Generation.

  • Rsa 署名アルゴリズム: 証明書は署名アルゴリズムとして RSA を使用する必要があります。RSA signature algorithm: The certificate must use RSA as the signature algorithm.

  • エクスポート可能な秘密キー: 証明書の生成に使用される秘密キーはエクスポート可能である必要があります。Exportable private key: The private key used to generate the certificate must be exportable. EAC で [Exchange 証明書の新規作成] ウィザードを使用するか、シェルで New-ExchangeCertificate コマンドレットを実行することで証明書要求を作成する場合に、秘密キーをエクスポート可能に指定します。You can specify that the private key be exportable when you create the certificate request using the New Exchange certificate wizard in the EAC or the New-ExchangeCertificate cmdlet in the Shell.

  • 現在の証明書: 証明書は現在のものである必要があります。Current certificate: The certificate must be current. 有効期限が切れた証明書や失効した証明書を使用して、フェデレーション信頼を作成することはできません。You can't use an expired or revoked certificate to create a federation trust.

  • 拡張キー使用法: 証明書には、拡張キー使用法 (EKU) タイプのクライアント認証 (1.3.6.1.5.5.7.3.2) が含まれている必要があります。Enhanced key usage: The certificate must include the enhanced key usage (EKU) type Client Authentication (1.3.6.1.5.5.7.3.2). この使用法タイプは、リモート コンピューターに自分の ID を提供するために使用されます。This usage type is used to prove your identity to a remote computer. EAC またはシェルを使用して証明書要求を生成する場合に、既定でこの使用法タイプが含まれます。If you use the EAC or the Shell to generate a certificate request, this usage type is included by default.

注意

認証のために証明書が使用されることがないため、証明書にはサブジェクト名やサブジェクトの別名についての要件はありません。ホスト名、ドメイン名、または他の何らかの名前と同じサブジェクト名を持つ証明書を使用することができます。Because the certificate isn't used for authentication, it doesn't have any subject name or subject alternative name requirements. You can use a certificate with a subject name that's the same as the host name, the domain name, or any other name.

新しい証明書への切り替えTransitioning to a new certificate

フェデレーション信頼を作成するために使用する証明書は、現在の証明書として指定されます。ただし、定期的にフェデレーション信頼の新しい証明書をインストールして使用しなければならない場合があります。たとえば、現在の証明書の期限が切れた場合、組織のビジネスやセキュリティの要件を満たす必要がある場合などに、新しい証明書を使用する必要があります。新しい証明書への移行をシームレスに実行するには、Exchange 2013 サーバー上に新しい証明書をインストールし、その証明書を新しい証明書として指定するようにフェデレーション信頼を構成する必要があります。Exchange 2013 によって、新しい証明書は組織内の他のすべての Exchange 2013 サーバーに自動的に配布されます。Active Directory トポロジによっては、証明書の配布に時間がかかる場合があります。シェルで Test-FederationTrustCertificate コマンドレットを使用すると、証明書の状態を確認できます。The certificate used to create the federation trust is designated as the current certificate. However, you may need to install and use a new certificate for the federation trust periodically. For example, you may need to use a new certificate if the current certificate expires or to meet a new business or security requirement. To ensure a seamless transition to a new certificate, you must install the new certificate on your Exchange 2013 server and configure the federation trust to designate it as the new certificate. Exchange 2013 automatically distributes the new certificate to all other Exchange 2013 servers in the organization. Depending on your Active Directory topology, distribution of the certificate may take a while. You can verify the certificate status using the Test-FederationTrustCertificate cmdlet in the Shell.

証明書の配布状態を確認したら、新しい証明書を使用するように信頼を構成します。証明書の切り替えを実行すると、現在の証明書は以前の証明書として指定され、新しい証明書が現在の証明書として指定されます。新しい証明書は Azure AD 認証システムに公開され、Azure AD 認証システムと交換されたすべての新しいトークンが新しい証明書を使用して暗号化されます。After you verify the certificate's distribution status, you can configure the trust to use the new certificate. After switching certificates, the current certificate is designated as the previous certificate, and the new certificate is designated as the current certificate. The new certificate is published to the Azure AD authentication system, and all new tokens exchanged with the Azure AD authentication system are encrypted using the new certificate.

注意

この証明書の切り替え処理は、フェデレーションによってのみ使用されます。証明書を必要とする Exchange 2013 の他の機能に同じ証明書を使用する場合は、新しい証明書の入手、インストール、および移行を計画する際にその機能の要件を考慮する必要があります。This certificate transition process is used only by federation. If you use the same certificate for other Exchange 2013 features that require certificates, you must take the feature requirements into consideration when planning to procure, install, or transition to a new certificate.

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

フェデレーション機能は、組織内のメールボックスおよびクライアント アクセス サーバーによる HTTPS を使用したインターネットへの送信アクセスを必要とします。Federation features require that the Mailbox and Client Access servers in your organization have outbound access to the Internet by using HTTPS. 組織内のすべての Exchange 2013 メールボックスおよびクライアント アクセス サーバーからの送信 HTTPS アクセス (TCP ポート 443) を許可する必要があります。You must allow outbound HTTPS access (port 443 for TCP) from all Exchange 2013 Mailbox and Client Access servers in the organization.

外部組織が組織の空き時間情報にアクセスするには、クライアント アクセス サーバーをインターネットに公開する必要があります。これには、インターネットからクライアント アクセス サーバーへの受信 HTTPS アクセスが必要です。クライアント アクセス サーバーをインターネットに公開していない Active Directory サイトのクライアント アクセス サーバーは、インターネットからアクセスできるその他の Active Directory サイトのクライアント アクセス サーバーを使用できます。インターネットに公開されていないクライアント アクセス サーバーは、外部組織から可視の URL で設定された Web サービス仮想ディレクトリの外部 URL が必要です。For an external organization to access your organization's free/busy information, you must publish one Client Access server to the Internet. This requires inbound HTTPS access from the Internet to the Client Access server. Client Access servers in Active Directory sites that don't have a Client Access server published to the Internet can use Client Access servers in other Active Directory sites that are accessible from the Internet. The Client Access servers that aren't published to the Internet must have the external URL of the Web services virtual directory set with the URL that's visible to external organizations.