在 Exchange 和 Exchange Online 组织之间配置 OAuth 身份验证

适用于: Exchange Server 2013

混合配置向导会自动在 Exchange 2013 与 Exchange Online 组织之间配置 OAuth 身份验证。 如果 Exchange 2013 组织包含 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 的此项功能与由世纪互联在中国运营的 Office 365 不完全兼容,可能需要遵循一些功能限制。 有关详细信息,请参阅由世纪互联运营的Office 365

在开始之前,您需要知道什么?

提示

是否有任何疑问? 在 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 访问控制服务 (ACS)

接下来,使用用于Windows PowerShell的 Azure Active Directory 模块将上一步导出的本地授权证书上传到 Azure Active Directory 访问控制服务 (ACS) 。 如果未安装模块,请以管理员身份打开Windows PowerShell窗口并运行以下命令:

Install-Module -Name MSOnline

安装 用于 Windows PowerShell 的 Azure Active Directory 模块 后,完成以下步骤。

  1. Click the Azure Active Directory Module for Windows PowerShell shortcut to open a Windows PowerShell workspace that has the Azure AD cmdlets installed. All commands in this step will be run using the Windows PowerShell for Azure Active Directory console.

  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:向 Azure Active Directory 注册内部和外部本地 Exchange HTTP 终结点的所有主机名颁发机构

需要在此步骤中为本地 Exchange 组织中每个可公开访问的终结点运行脚本,包括混合新式身份验证) 的内部和外部 URL。 例如,如果 Exchange 在外部可用 https://mail.contoso.com/ews/exchange.asmx,请使用服务主体名称 https://mail.contoso.com。 注册其他外部主机名颁发机构并无限制。

若要确认本地组织中的 Exchange 终结点,请在 Exchange Management Shell 中运行以下命令:

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

备注

以下脚本要求 Azure Active Directory 的Windows PowerShell已连接到 Microsoft 365 组织,如上一部分的步骤 4 中所述。

  1. 将以下文本保存到名为 RegisterEndpoints.ps1(示例名称)的 PowerShell 脚本文件中。 此示例使用 contoso.com。 替换 https://mail.contoso.com/https://autodiscover.contoso.com/ 替换为本地 Exchange 组织的相应主机名颁发机构。

    $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. 若要验证是否添加了所有记录,请在 Azure Active Directory 的Windows PowerShell中运行以下命令,并在结果中查找https://namespace条目。

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

步骤 6:从本地组织创建 IntraOrganizationConnector 到 Microsoft 365 或 Office 365

必须为在 Exchange Online 中托管的邮箱定义目标地址。 创建 Microsoft 365 或Office 365组织时,会自动创建此目标地址。 例如,如果组织在 Microsoft 365 或Office 365组织中托管的域为“contoso.com”,则目标服务地址将为“contoso.mail.onmicrosoft.com”。

使用 Exchange PowerShell 在本地组织中运行以下 cmdlet:

$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组织创建 IntraOrganizationConnector 到本地 Exchange 组织

必须为在本地组织中托管的邮箱定义目标地址。 如果组织的主 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 cmdlet 来确定 New-IntraOrganizationConnector cmdlet 所需的终结点值。

连接到 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 组织中配置混合部署时,至少需要一台运行 Exchange 2013 SP1 或更高版本的 Exchange 2013 服务器。 Exchange 2013 服务器需要客户端访问和邮箱服务器角色。 Exchange 2013 服务器协调现有 Exchange 本地组织与Exchange Online组织之间的通信。 我们强烈建议在内部部署组织中安装多个 Exchange 2013 服务器,以帮助提高混合部署功能的可靠性和可用性。

在 Exchange 2010 或 Exchange 2007 的 Exchange 2013 组织中,我们建议所有面向 Internet 的前端服务器都是运行 SP1 或更高版本的 Exchange 2013 客户端访问服务器。 所有 Exchange Web 服务 (EWS) 请求都必须通过 Exchange 2013 客户端访问服务器。 此要求包括从 Microsoft 365 到本地 Exchange 组织的请求,以及从本地 Exchange 组织到 Microsoft 365 的请求。 必须有足够的 Exchange 2013 客户端访问服务器来处理处理负载并提供连接冗余。 所需的客户端访问服务器数取决于 EWS 请求的平均数量,并且因组织而异。

完成下面的步骤之前,请确保:

  • 前端混合服务器是 Exchange 2013 SP1 或更高版本。
  • 您对 Exchange 2013 服务器具有唯一的外部 EWS URL。 Microsoft 365 或 Office 365 组织必须连接到这些服务器,以便基于云的混合功能请求能够正常工作。
  • 服务器具有邮箱服务器和客户端访问服务器角色
  • 任何现有的 Exchange 2010/2007 邮箱服务器和客户端访问服务器都应用了最新的累积更新 (CU) 或 Service Pack (SP)。

备注

现有的 Exchange 2010/2007 邮箱服务器可以继续使用 Exchange 2010/2007 客户端访问服务器,作为非混合功能连接的前端服务器。 只有来自 Microsoft 365 或Office 365组织的混合部署功能请求需要连接到 Exchange 2013 服务器。

必须在指向本地 Exchange 2013 SP1 客户端访问服务器的 Exchange 2013 客户端访问服务器的 Exchange 2013 客户端访问服务器 () 的 Exchange Web Services 终结点上配置 AvailabilityAddressSpace 。 此终结点是步骤 5 之前介绍的同一个终结点,您也可以通过在本地 Exchange 2013 SP1 客户端访问服务器上运行以下 cmdlet 来确定此终结点:

Get-WebServicesVirtualDirectory | Format-List AdminDisplayVersion,ExternalUrl

备注

如果从多个服务器返回虚拟目录信息,请确保使用为 Exchange 2013 SP1 客户端访问服务器返回的终结点。 它将为 AdminDisplayVersion 参数显示 15.0 (内部版本 847.32) 或更高版本。

要配置 AvailabilityAddressSpace,请使用 Exchange PowerShell 并在内部部署组织中运行以下 cmdlet:

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 cmdlet 验证 OAuth 配置是否正确。此 cmdlet 可验证本地 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