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

製品: Exchange Server 2013

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

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

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

Exchange 2013 および Exchange Online とのハイブリッド展開を実装する、Exchange が混在するすべての組織では、ハイブリッド構成ウィザードでハイブリッド展開を構成した後に、Exchange OAuth 認証を構成することをお勧めします。

重要

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

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

始める前に把握しておくべき情報

ヒント

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

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

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

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

オンプレミスのExchange組織の Exchange Management Shell (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組織にインポートされます。

  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: オンプレミス認証証明書を Azure Active Directory Access Control Service (ACS) にアップロードする

次に、Windows PowerShell を使用して、直前の手順でエクスポートしたオンプレミスの認証証明書を Azure Active Directory アクセス制御サービス (ACS) にアップロードする必要があります。 これを行うには、Windows PowerShell の Azure Active Directory モジュール コマンドレットをインストールする必要があります。 インストールされていない場合は、adminsitrator として実行される Powershell で次のコマンドを実行して、Windows PowerShell用のAzure Active Directory モジュールをインストールします。

Install-Module -Name MSOnline

Windows PowerShell の Azure Active Directory モジュール のインストール後、以下の手順を実行します。

  1. [Windows PowerShell 用 Azure Active Directory モジュール] ショートカットをクリックして、Azure AD コマンドレットがインストールされた Windows PowerShell ワークスペースを開きます。この手順のすべてのコマンドは、Azure Active Directory コンソール用の 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 Azure AD 組織のテナント管理者アカウントの資格情報を入力します。スクリプトの実行後、Azure AD 用 Windows PowerShell セッションを開いたままにします。これは、次のステップで PowerShell スクリプトを実行するために使用します。

手順 5: 内部および外部のオンプレミスExchange HTTP エンドポイントのすべてのホスト名機関をAzure Active Directoryに登録する

この手順では、パブリックにアクセスできるオンプレミスのExchange組織のエンドポイントごとにスクリプトを実行する必要があります (ハイブリッドモダン認証を設定する場合は内部 URL と外部 URL)。 たとえば、Exchangeが外部で使用できると https://mail.contoso.com/ews/exchange.asmx します。 この場合、次のサービス プリンシパル名が https://mail.contoso.com 使用されます。 追加の外部ホスト名機関の登録には制限はありません。

オンプレミスのExchange組織内のExchange エンドポイントがわからない場合は、オンプレミスのExchange組織の PowerShell で次のコマンドExchange実行して、外部構成された Web サービス エンドポイントの一覧を取得できます。

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

注意

以下のスクリプトを正常に実行するためには、直前のセクションのステップ 4 で説明されているように、Azure Active Directory 用 Windows PowerShell が Microsoft Online Azure AD テナントに接続されている必要があります。

  1. 次のテキストを、たとえば RegisterEndpoints.ps1 という名前の PowerShell スクリプト ファイルに保存します。 この例では、contoso.com を使用します。 オンプレミスのExchange組織に適したホスト名機関に置き換えますhttps://mail.contoso.com/ & https://autodiscover.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. Azure Active Directory 用 Windows PowerShell で、直前のステップで作成した Windows PowerShell スクリプトを実行します。たとえば、次のようにです。

    .\RegisterEndpoints.ps1
    
  3. すべてのレコードが追加されたことを確認するには、次を実行する必要があります。 00000002-00000-0ff1-ce00-000000000000/名前空間エントリではなく、すべての URL のエントリを探 https://namespace しています。

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

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

Exchange Online でホストされるメールボックスのターゲット アドレスを定義する必要があります。 このターゲット アドレスは、Microsoft 365またはOffice 365組織が作成されたときに自動的に作成されます。 たとえば、Microsoft 365またはOffice 365組織でホストされている組織のドメインが "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またはOffice 365組織からオンプレミスのExchange組織に IntraOrganizationConnector を作成する

社内の組織でホストされているメールボックスのターゲット アドレスを定義する必要があります。 組織のプライマリ SMTP アドレスが "contoso.com" の場合、これは "contoso.com" になります。 また、社内の組織の外部自動検出エンドポイントも定義する必要があります。 企業が "contoso.com" の場合、これは通常は次のいずれかとなります。

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

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

注意

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

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

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

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

Exchange 2013 より前の組織でハイブリッド展開を構成する場合、クライアント アクセス サーバーおよびメールボックス サーバーの役割を持つ少なくとも 1 つの Exchange 2013 SP1 以上のサーバーを、既存の Exchange 組織にインストールする必要があります。Exchange 2013 クライアント アクセス サーバーおよびメールボックス サーバーは、フロントエンド サーバーの役割をし、既存の Exchange 社内組織と Exchange Online 組織間の通信を調整します。この通信には、社内組織と Exchange Online 組織間のメッセージ トランスポート機能およびメッセージング機能が使用されます。ハイブリッド展開機能の信頼性と可用性を向上するために、社内組織に 2 台以上の Exchange 2013 サーバーを展開することを強くお勧めします。

Exchange 2013/2010 または Exchange 2013/2007 が含まれる混在展開では、インターネットに直接接続されたすべての社内組織用サーバーを、Exchange 2013 SP1 以上が実行されているクライアント アクセス サーバーにすることをお勧めします。 Microsoft 365またはOffice 365およびExchange Onlineから発信されるすべてのExchange Web サービス (EWS) 要求は、オンプレミス展開内の Exchange 2013 クライアント アクセス サーバーに接続する必要があります。 さらに、Exchange Online の社内 Exchange 組織からのすべての EWS 要求は、Exchange 2013 SP1 以上が実行されているクライアント アクセス サーバーを介してプロキシされる必要があります。 これらの Exchange 2013 クライアント アクセス サーバーはこの追加の受信および送信 EWS 要求を処理する必要があるため、処理負荷を扱い、接続の冗長性を提供する十分な数の Exchange 2013 クライアント アクセス サーバーが備わっていることが重要です。 必要なクライアント アクセス サーバーの数は、EWS 要求の平均量に依存しており、組織によって異なります。

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

  • フロントエンド ハイブリッド サーバーが Exchange 2013 SP1 以上である

  • Exchange 2013 サーバー用の一意の外部 EWS URL がある。 ハイブリッド機能のクラウドベースの要求が正しく機能するためには、Microsoft 365またはOffice 365組織がこれらのサーバーに接続する必要があります。

  • サーバーにメールボックス サーバーとクライアント アクセス サーバーの両方の役割がある

  • 既存の Exchange 2010/2007 メールボックス サーバーおよびクライアント アクセス サーバーに、最新の累積更新プログラム (CU) またはサービス パック (SP) が適用されている。

注意

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

AvailabilityAddressSpace は、オンプレミス Exchange Exchange 2013 SP1 クライアント アクセス サーバーのExchange Web サービス エンドポイントを指す 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組織がオンプレミスのExchange組織に正常に接続できることを確認するには、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 にアクセスしてください。