Exchange と Exchange Online 組織の間の OAuth 認証を構成する

製品: Exchange Server 2013

ハイブリッド構成ウィザードでは、Exchange 2013 と Exchange Online 組織の間で OAuth 認証が自動的に構成されます。 Exchange 2013 organizationに Exchange 2010 または Exchange 2007 サーバーが含まれている場合、ハイブリッド構成ウィザードでは、オンプレミスとオンラインの Exchange 組織間で OAuth 認証が構成されません。 既定では、これらの展開は引き続きフェデレーション信頼プロセスを使用します。 ただし、特定の Exchange 2013 機能は、新しい Exchange OAuth 認証プロトコルを使用してはじめて、組織間で完全に使用できます。

現在のところ、新しい Exchange OAuth 認証プロセスにより Exchange の機能のうち以下のものが有効になります。

  • メッセージ レコード管理 (MRM)
  • Exchange のインプレース電子情報開示
  • Exchange インプレース アーカイブ

ハイブリッド構成ウィザードを実行した後、すべての混合 Exchange 2013 組織で Exchange OAuth 認証を構成することをお勧めします。

重要

  • オンプレミスの組織で、累積更新プログラム 5 以降のインストールされた Exchange 2013 サーバーだけが実行されている場合は、このトピックの手順を実行する代わりにハイブリッド展開ウィザードを実行します。

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

はじめに把握しておくべき情報

  • このタスクの予想所要時間:15 分。

  • この手順を実行する際には、あらかじめアクセス許可が割り当てられている必要があります。 必要なアクセス許可を確認するには、「 Exchange とシェルのインフラストラクチャ のアクセス許可」トピックの「フェデレーションと証明書」のアクセス許可エントリを参照してください。

  • ハイブリッド展開ウィザードを使用して完成させた、ハイブリッド展開の構成。 詳細については、「ハイブリッドデプロイのExchange Server」を参照してください。

  • このトピックの手順で使用可能なキーボード ショートカットについては、「Exchange 管理センターのキーボード ショートカット」を参照してください。

ヒント

問題がある場合は、 Exchange のフォーラムで質問してください。 Exchange Serverのフォーラムにアクセスしてください。

社内の Exchange 組織と Exchange Online 組織の間で OAuth の認証を構成する方法

手順 1: Exchange Online organizationの承認サーバー オブジェクトを作成する

この手順では、Exchange Online 組織のために検証済みのドメインを指定する必要があります。 これは、クラウドベースの電子メール アカウントに使用されるプライマリ SMTP ドメインと同じドメインである必要があります。 このドメインは、次の手順で検証済みドメイン>と<呼ばれます。

オンプレミスの Exchange organizationの Exchange 管理シェル (Exchange PowerShell) で次のコマンドを実行します。

New-AuthServer -Name "WindowsAzureACS" -AuthMetadataUrl "https://accounts.accesscontrol.windows.net/<your tenant coexistence domain>/metadata/json/1"
New-AuthServer -Name "evoSTS" -Type AzureAD -AuthMetadataUrl "https://login.windows.net/<your tenant coexistence domain>/federationmetadata/2007-06/federationmetadata.xml"

注:

GCC High または DoD では、代わりに次のコマンドを使用する必要があります。

New-AuthServer -Name "WindowsAzureACS" -AuthMetadataUrl "https://login.microsoftonline.us/<your tenant coexistence domain>/metadata/json/1"
New-AuthServer -Name "evoSTS" -Type AzureAD -AuthMetadataUrl "https://login.microsoftonline.us/<your tenant coexistence domain>/federationmetadata/2007-06/federationmetadata.xml"

注:

テナント共存ドメインは、contoso.mail.onmicrosoft.com 形式です

ステップ 2:Exchange Online 組織のパートナー アプリケーションを使用可能にする

社内 Exchange 組織の Exchange PowerShell で、次のコマンドを実行します。

Get-PartnerApplication |  ?{$_.ApplicationIdentifier -eq "00000002-0000-0ff1-ce00-000000000000" -and $_.Realm -eq ""} | Set-PartnerApplication -Enabled $true

ステップ 3:社内の認証証明書をエクスポートする

この手順では、Exchange サーバーで PowerShell スクリプトを直接実行してオンプレミスの承認証明書をエクスポートし、次の手順でExchange Online organizationにインポートする必要があります。

  1. 次のテキストを、たとえば ExportAuthCert.ps1 という名前の PowerShell スクリプト ファイルに保存します。

    $thumbprint = (Get-AuthConfig).CurrentCertificateThumbprint
    if((test-path $env:SYSTEMDRIVE\OAuthConfig) -eq $false)
    {
       md $env:SYSTEMDRIVE\OAuthConfig
    }
    cd $env:SYSTEMDRIVE\OAuthConfig
    $oAuthCert = (dir Cert:\LocalMachine\My) | where {$_.Thumbprint -match $thumbprint}
    $certType = [System.Security.Cryptography.X509Certificates.X509ContentType]::Cert
    $certBytes = $oAuthCert.Export($certType)
    $CertFile = "$env:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer"
    [System.IO.File]::WriteAllBytes($CertFile, $certBytes)
    
  2. 社内 Exchange 組織の Exchange PowerShell で、直前の手順で作成した PowerShell スクリプトを実行します。 例:

    .\ExportAuthCert.ps1
    

手順 4: オンプレミスの承認証明書を Microsoft Entra Access Control Service (ACS) にアップロードする

次に、Windows PowerShell用の Azure Active Directory モジュールを使用して、前の手順でエクスポートしたオンプレミスの承認証明書を Microsoft Entra Access Control Services (ACS) にアップロードします。 モジュールがインストールされていない場合は、管理者としてWindows PowerShell ウィンドウを開き、次のコマンドを実行します。

Install-Module -Name MSOnline

Windows PowerShell用の Azure Active Directory モジュールがインストールされたら、次の手順を実行します。

  1. Microsoft Entra コマンドレットがインストールされているWindows PowerShell ワークスペースを開くには、Windows PowerShell ショートカットの Azure Active Directory モジュールをクリックします。 この手順のすべてのコマンドは、Microsoft Entra ID コンソールのWindows PowerShellを使用して実行されます。

  2. 次のテキストを、たとえば UploadAuthCert.ps1 という名前の PowerShell スクリプト ファイルに保存します。

    Connect-MsolService
    $CertFile = "$env:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer"
    $objFSO = New-Object -ComObject Scripting.FileSystemObject
    $CertFile = $objFSO.GetAbsolutePathName($CertFile)
    $cer = New-Object System.Security.Cryptography.X509Certificates.X509Certificate
    $cer.Import($CertFile)
    $binCert = $cer.GetRawCertData()
    $credValue = [System.Convert]::ToBase64String($binCert)
    $ServiceName = "00000002-0000-0ff1-ce00-000000000000"
    $p = Get-MsolServicePrincipal -ServicePrincipalName $ServiceName
    New-MsolServicePrincipalCredential -AppPrincipalId $p.AppPrincipalId -Type asymmetric -Usage Verify -Value $credValue
    
  3. 直前の手順で作成した PowerShell スクリプトを実行します。 たとえば、

    .\UploadAuthCert.ps1
    
  4. スクリプトを起動した後に、[資格情報] ダイアログ ボックスが表示されます。 Microsoft Online Microsoft Entra organizationでテナント管理者アカウントの資格情報を入力します。 スクリプトを実行した後、セッションのWindows PowerShell Microsoft Entra開いたままにします。 これは、次のステップで PowerShell スクリプトを実行するために使用します。

手順 5: Microsoft Entra ID を使用して、内部および外部のオンプレミス Exchange HTTP エンドポイントのすべてのホスト名機関を登録する

この手順では、ハイブリッド先進認証の内部 URL と外部 URL を含む、オンプレミスの Exchange organization内のパブリックにアクセス可能なエンドポイントごとにスクリプトを実行する必要があります。 たとえば、Exchange が で https://mail.contoso.com/ews/exchange.asmx外部から使用できる場合は、サービス プリンシパル名 を使用します https://mail.contoso.com。 追加の外部ホスト名機関を登録するための制限はありません。

オンプレミスのorganizationで Exchange エンドポイントを確認するには、Exchange 管理シェルで次のコマンドを実行します。

Get-MapiVirtualDirectory | FL server,*url*
Get-WebServicesVirtualDirectory | FL server,*url*
Get-OABVirtualDirectory | FL server,*url*

注:

次のスクリプトでは、前のセクションの手順 4 で説明したように、Microsoft Entra ID のWindows PowerShellが Microsoft 365 organizationに接続されている必要があります。

  1. 次のテキストを、たとえば RegisterEndpoints.ps1 という名前の PowerShell スクリプト ファイルに保存します。 この例では、contoso.com を使用します。 と https://autodiscover.contoso.com/ を、オンプレミスの Exchange organizationの適切なホスト名機関に置き換えますhttps://mail.contoso.com/

    $ServiceName = "00000002-0000-0ff1-ce00-000000000000";
    $x = Get-MsolServicePrincipal -AppPrincipalId $ServiceName;
    $x.ServicePrincipalnames.Add("https://mail.contoso.com/");
    $x.ServicePrincipalnames.Add("https://autodiscover.contoso.com/");
    Set-MSOLServicePrincipal -AppPrincipalId $ServiceName -ServicePrincipalNames $x.ServicePrincipalNames;
    
  2. Microsoft Entra ID のWindows PowerShellで、前の手順で作成したWindows PowerShell スクリプトを実行します。 例:

    .\RegisterEndpoints.ps1
    
  3. すべてのレコードが追加されたことを確認するには、Microsoft Entra ID のWindows PowerShellで次のコマンドを実行し、結果のエントリを探https://namespaceします。

    Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 | select -ExpandProperty ServicePrincipalNames
    

手順 6: オンプレミスのorganizationから Microsoft 365 または Office 365 に IntraOrganizationConnector を作成する

Exchange Online でホストされるメールボックスのターゲット アドレスを定義する必要があります。 このターゲット アドレスは、Microsoft 365 またはOffice 365 organizationの作成時に自動的に作成されます。 たとえば、Microsoft 365 または Office 365 organization でホストされているorganizationのドメインが "contoso.com" の場合、ターゲット サービス アドレスは "contoso.mail.onmicrosoft.com" になります。

Exchange PowerShell を使用して、社内の組織で次のコマンドレットを実行します。

$ServiceDomain = Get-AcceptedDomain | where {$_.DomainName -like "*.mail.onmicrosoft.com"} | select -ExpandProperty Name
New-IntraOrganizationConnector -name ExchangeHybridOnPremisesToOnline -DiscoveryEndpoint https://outlook.office365.com/autodiscover/autodiscover.svc -TargetAddressDomains $ServiceDomain

手順 7: Microsoft 365 から IntraOrganizationConnector を作成するか、オンプレミスの Exchange organizationにOffice 365 organizationする

社内の組織でホストされているメールボックスのターゲット アドレスを定義する必要があります。 organizationのプライマリ SMTP アドレスが "contoso.com" にある場合、ターゲット アドレスは "contoso.com" になります。

また、社内の組織の外部自動検出エンドポイントも定義する必要があります。 会社が "contoso.com" の場合、自動検出エンドポイントは通常、次のいずれかの値です。

  • https://autodiscover.<your primary SMTP domain>/autodiscover/autodiscover.svc
  • https://<your primary SMTP domain>/autodiscover/autodiscover.svc>

注:

オンプレミステナントと Microsoft 365 テナントまたは Office 365 テナントの両方で Get-IntraOrganizationConfiguration コマンドレットを使用して、New-IntraOrganizationConnector コマンドレットで必要なエンドポイント値を決定できます。

PowerShell Exchange Onlineに接続したら、 と <your on-premises SMTP domain> を自分の値に置き換えて<your on-premises Autodiscover endpoint>、次のコマンドを実行します。

New-IntraOrganizationConnector -name ExchangeHybridOnlineToOnPremises -DiscoveryEndpoint <your on-premises Autodiscover endpoint> -TargetAddressDomains <your on-premises SMTP domain>

ステップ 8:Exchange 2013 SP1 よりも前のサーバー用に AvailabilityAddressSpace を構成する

古い Exchange 組織でハイブリッド展開を構成する場合は、Exchange 2013 SP1 以降を実行している Exchange 2013 サーバーが少なくとも 1 つ必要です。 Exchange 2013 サーバーには、クライアント アクセス サーバーとメールボックス サーバーの役割が必要です。 Exchange 2013 サーバーは、既存の Exchange オンプレミス organizationとExchange Online organization間の通信を調整します。 ハイブリッド展開機能の信頼性と可用性を向上させために、社内組織に複数の Exchange 2013 サーバーを設置することを強くお勧めします。

Exchange 2010 または Exchange 2007 を使用する Exchange 2013 組織では、インターネットに接続するすべてのフロントエンド サーバーが SP1 以降を実行している Exchange 2013 クライアント アクセス サーバーであることをお勧めします。 すべての Exchange Web サービス (EWS) 要求は、Exchange 2013 クライアント アクセス サーバーを経由する必要があります。 この要件には、Microsoft 365 からオンプレミスの Exchange organizationへの要求と、オンプレミスの Exchange organizationから Microsoft 365 への要求が含まれます。 処理負荷を処理し、接続の冗長性を提供するのに十分な Exchange 2013 クライアント アクセス サーバーが必要です。 必要なクライアント アクセス サーバーの数は、EWS 要求の平均量によって異なり、organizationによって異なります。

次の手順を完了する前に、以下の点を確認してください。

  • フロントエンド ハイブリッド サーバーは、Exchange 2013 SP1 以降です。
  • Exchange 2013 サーバー用の一意の外部 EWS URL がある。 Microsoft 365 または Office 365 organizationは、ハイブリッド機能のクラウドベースの要求が正しく機能するためには、これらのサーバーに接続する必要があります。
  • サーバーにメールボックス サーバーとクライアント アクセス サーバーの両方の役割がある
  • 既存の Exchange 2010/2007 メールボックス サーバーおよびクライアント アクセス サーバーに、最新の累積更新プログラム (CU) またはサービス パック (SP) が適用されている。

注:

既存の Exchange 2010/2007 メールボックス サーバーは、非ハイブリッド機能接続用に Exchange 2010/2007 クライアント アクセス サーバーをフロントエンド サーバーとして引き続き使用できます。 Exchange 2013 サーバーに接続する必要があるのは、Microsoft 365 または Office 365 organization からのハイブリッド展開機能の要求のみです。

AvailabilityAddressSpace は、オンプレミスの Exchange 2013 SP1 クライアント アクセス サーバーの Exchange Web サービス エンドポイントを指す Exchange 2013 以前のクライアント アクセス サーバーで構成する必要があります。 このエンドポイントは、手順 5 で概説したエンドポイントと同じものですが、社内の Exchange 2013 SP1 クライアント アクセス サーバーから、次のコマンドレットを実行することで判別できます。

Get-WebServicesVirtualDirectory | Format-List AdminDisplayVersion,ExternalUrl

注:

複数のサーバーから仮想ディレクトリ情報が返ってくる場合は、Exchange 2013 SP1 クライアント アクセス サーバーへ返されたエンドポイントを使用していることを確認してください。 AdminDisplayVersion パラメーターには 15.0 (ビルド 847.32) 以上が表示されます。

AvailabilityAddressSpace を構成するには、社内組織で Exchange PowerShell を使用して、次のコマンドレットを実行します。

Add-AvailabilityAddressSpace -AccessMethod InternalProxy -ProxyUrl <your on-premises External Web Services URL> -ForestName <your Microsoft 365 or Office 365 service target address> -UseServiceAccount $True

正常な動作を確認する方法

Test-OAuthConnectivity コマンドレットを使用して、OAuth 構成が正しいことを検証できます。 このコマンドレットは、社内の Exchange と Exchange Online のエンドポイントが、相互からの要求を正常に認証できることを検証します。

社内の Exchange 組織が Exchange Online に正常に接続できることを検証するために、社内の組織の Exchange PowerShell で次のコマンドを実行します。

Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/ews/exchange.asmx -Mailbox <On-Premises Mailbox> -Verbose | Format-List

Exchange Online organizationがオンプレミスの Exchange organizationに正常に接続できることを確認するには、Exchange Online PowerShell に接続し、次のコマンドを実行します。

Test-OAuthConnectivity -Service EWS -TargetUri <external hostname authority of your Exchange On-Premises deployment>/metadata/json/1 -Mailbox <Exchange Online Mailbox> -Verbose | Format-List

したがって、例として、

Test-OAuthConnectivity -Service EWS -TargetUri `https://mail.contoso.com/metadata/json/1` -Mailbox ExchangeOnlineBox1 -Verbose | Format-List

重要

"SMTP アドレスにメールボックスが関連付けられていない" というエラーは無視できます。 ResultTask パラメーターが Success の値を返すのが重要です。 たとえば、テスト出力の最後のセクションは次のようになります。

ResultType: Success Identity: Microsoft.Exchange.Security.OAuth.ValidationResultNodeId IsValid: True ObjectState: New

ヒント

問題がある場合は、 Exchange のフォーラムで質問してください。 Exchange Serverのフォーラムにアクセスしてください。