Partilhar via

Configurar a autenticação OAuth entre organizações do Exchange e do Exchange Online

  • Artigo

O assistente de Configuração Híbrida configura automaticamente a autenticação OAuth entre organizações do Exchange Server no local e do Exchange Online. Se a sua organização do Exchange contiver servidores do Exchange 2010 ou exchange 2007, o assistente de Configuração Híbrida não configura a autenticação OAuth entre as organizações do Exchange no local e online. Essas implantações continuam a usar o processo de confiança de federação por padrão. No entanto, determinadas funcionalidades só estão totalmente disponíveis na sua organização através do novo protocolo de autenticação OAuth do Exchange.

O novo processo de autenticação OAuth do Exchange permite atualmente os seguintes recursos do Exchange:

  • Gestão de Registos de Mensagens (MRM)
  • Descoberta eletrônica in-loco do Exchange
  • Arquivamento In-loco do Exchange

Recomendamos que todas as organizações mistas do Exchange 2013 configurem a autenticação OAuth do Exchange depois de executarem o Assistente de Configuração Híbrida.

Importante

  • Se a sua organização no local estiver a executar apenas servidores do Exchange 2013 com a Atualização Cumulativa 5 ou posterior, o Exchange 2016 ou o Exchange 2019, execute o Assistente de Configuração Híbrida em vez de executar os passos neste tópico.

  • Esse recurso do Exchange Server 2013 não é totalmente compatível com o Office 365 operado pelo 21Vianet na China e pode haver algumas limitações de recurso. Para obter mais informações, consulte Office 365 operado pela 21Vianet.

Do que você precisa saber para começar?

Dica

Está com problemas? Peça ajuda nos fóruns do Exchange. Visite os fóruns no Exchange Server.

Como você configura a autenticação OAuth entre suas organizações do Exchange local e do Exchange Online?

Glossário

Domínio inicial: o primeiro domínio aprovisionado no inquilino. Por exemplo, contoso.onmicrosoft.com. É referido como <o seu domínio> inicial de inquilino nesta documentação.

Domínio de encaminhamento híbrido: o domínio de encaminhamento híbrido em ambientes híbridos do Exchange, como contoso.mail.onmicrosoft.com, é utilizado para gerir o fluxo de correio entre servidores exchange no local e o Exchange Online. Garante uma comunicação totalmente integrada e a entrega de mensagens em ambos os ambientes. É referido como <o seu domínio> de encaminhamento híbrido nesta documentação.

Endereço de Encaminhamento de E-mail da Microsoft Online (MOERA): o endereço construído a partir do prefixo do userPrincipalName utilizador, bem como o sufixo de domínio inicial, que é adicionado automaticamente ao no ID do proxyAddress Microsoft Entra. Por exemplo, smtp:john.doe@contoso.onmicrosoft.com. Não utilizamos o MOERA nesta documentação, mas listamo-lo aqui por uma questão de completo.

Domínio SMTP principal: o domínio SMTP principal no Microsoft Exchange Server é o domínio principal utilizado para endereços de e-mail na organização. É referido como <o seu domínio> SMTP principal nesta documentação.

Ponto final de Deteção Automática: o ponto final de Deteção Automática é um URL do serviço Web que fornece informações de configuração do Exchange Server. Permite que as aplicações descubram e liguem automaticamente aos serviços do Exchange. Se a sua empresa utilizar, por exemplo, contoso.com como domínio SMTP principal, o ponto final de Deteção Automática é normalmente https://autodiscover.contoso.com/autodiscover/autodiscover.svc ou https://contoso.com/autodiscover/autodiscover.svc. É referido como <o ponto> final de Deteção Automática no local nesta documentação.

Exchange Web Services (EWS): o Exchange Web Services (EWS) é uma API para várias plataformas que permite que as aplicações acedam a itens de caixa de correio, como mensagens de e-mail, reuniões e contactos. É referido como <o URL> dos Serviços Web do Exchange externos no local nesta documentação.

Passo 1: criar os objetos do servidor de autorização para a sua organização do Exchange Online

Execute o seguinte comando na Shell de Gestão do Exchange (Exchange PowerShell) na sua organização do Exchange no local. Certifique-se de que substitui os marcadores de posição pelos seus valores antes de executar o comando:

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

Em GCC High ou DoD, tem de utilizar os seguintes comandos:

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

Etapa 2: habilitar o aplicativo parceiro para sua organização do Exchange Online

Execute o seguinte comando no Exchange PowerShell na sua organização do Exchange no local:

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

Etapa 3: exportar o certificado de autorização local

Neste passo, tem de executar um script do PowerShell no servidor Exchange diretamente para exportar o certificado de autorização no local, que é depois importado para a sua organização do Exchange Online no próximo passo.

  1. Salve o seguinte texto em um script do PowerShell chamado, por exemplo, de ExportAuthCert.ps1.

    Observação

    Se quiser carregar o certificado que está configurado para se tornar no novo certificado de autenticação no futuro, substitua por $thumbprint = (Get-AuthConfig).CurrentCertificateThumbprint$thumbprint = (Get-AuthConfig).NewCertificateThumbprint.

    $thumbprint = (Get-AuthConfig).CurrentCertificateThumbprint
if((Test-Path $env:SYSTEMDRIVE\OAuthConfig) -eq $false)
{
   New-Item -Path $env:SYSTEMDRIVE\OAuthConfig -Type Directory
}
Set-Location -Path $env:SYSTEMDRIVE\OAuthConfig
$oAuthCert = (dir Cert:\LocalMachine\My) | Where-Object {$_.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. No Exchange PowerShell em sua organização local do Exchange, execute o script do PowerShell criado na etapa anterior. Por exemplo:

    .\ExportAuthCert.ps1

Passo 4: Carregar o certificado de autorização no local para o Serviço de Controlo de Acesso do Microsoft Entra (ACS)

Em seguida, utilize o Microsoft Graph PowerShell para carregar o certificado de autorização no local que exportou no passo anterior para o Microsoft Entra Access Control Services (ACS). Se não tiver o módulo instalado, abra uma janela do Windows PowerShell como administrador e execute o seguinte comando:

Install-Module -Name Microsoft.Graph.Applications

Conclua os seguintes passos após a instalação do PowerShell do Microsoft Graph.

  1. Abra uma área de trabalho do Windows PowerShell que tenha os cmdlets do Microsoft Graph instalados. Todos os comandos neste passo serão executados com o Windows PowerShell ligado à consola do Microsoft Graph.

  2. Salve o seguinte texto em um script do PowerShell chamado, por exemplo, de UploadAuthCert.ps1.

    Connect-MgGraph -Scopes Application.ReadWrite.All

$CertFile = "$env:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer"
$objFSO = New-Object -ComObject Scripting.FileSystemObject
$CertFile = $objFSO.GetAbsolutePathName($CertFile)
$cer = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new($CertFile)
$binCert = $cer.GetRawCertData()
$credValue = [System.Convert]::ToBase64String($binCert)
$ServiceName = "00000002-0000-0ff1-ce00-000000000000"
Write-Host "[+] Trying to query the service principals for service: $ServiceName" -ForegroundColor Cyan
$p = Get-MgServicePrincipal -Filter "AppId eq '$ServiceName'"
Write-Host "[+] Trying to query the keyCredentials for service: $ServiceName" -ForegroundColor Cyan
$servicePrincipalKeyInformation = Get-MgServicePrincipal -Filter "AppId eq '$ServiceName'" -Select "keyCredentials"

$keyCredentialsLength = $servicePrincipalKeyInformation.KeyCredentials.Length
if ($keyCredentialsLength -gt 0) {
   Write-Host "[+] $keyCredentialsLength existing key(s) found - we keep them if they have not expired" -ForegroundColor Cyan

   $newCertAlreadyExists = $false
   $servicePrincipalObj = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphServicePrincipal
   $keyCredentialsArray = @()

   foreach ($cred in $servicePrincipalKeyInformation.KeyCredentials) {
      $thumbprint = [System.Convert]::ToBase64String($cred.CustomKeyIdentifier)

      Write-Host "[+] Processing existing key: $($cred.DisplayName) thumbprint: $thumbprint" -ForegroundColor Cyan

      if ($newCertAlreadyExists -ne $true) {
         $newCertAlreadyExists = ($cer.Thumbprint).Equals($thumbprint, [System.StringComparison]::OrdinalIgnoreCase)
      }

      if ($cred.EndDateTime -lt (Get-Date)) {
         Write-Host "[+] This key has expired on $($cred.EndDateTime) and will not be retained" -ForegroundColor Yellow
         continue
      }

      $keyCredential = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphKeyCredential
      $keyCredential.Type = "AsymmetricX509Cert"
      $keyCredential.Usage = "Verify"
      $keyCredential.Key = $cred.Key

      $keyCredentialsArray += $keyCredential
   }


   if ($newCertAlreadyExists -eq $false) {
      Write-Host "[+] New key: $($cer.Subject) thumbprint: $($cer.Thumbprint) will be added" -ForegroundColor Cyan
      $keyCredential = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphKeyCredential
      $keyCredential.Type = "AsymmetricX509Cert"
      $keyCredential.Usage = "Verify"
      $keyCredential.Key = [System.Text.Encoding]::ASCII.GetBytes($credValue)

      $keyCredentialsArray += $keyCredential

      $servicePrincipalObj.KeyCredentials = $keyCredentialsArray
      Update-MgServicePrincipal -ServicePrincipalId $p.Id -BodyParameter $servicePrincipalObj
   } else {
      Write-Host "[+] New key: $($cer.Subject) thumbprint: $($cer.Thumbprint) already exists and will not be uploaded again" -ForegroundColor Yellow
   }
} else {
   $params = @{
      type = "AsymmetricX509Cert"
      usage = "Verify"
      key = [System.Text.Encoding]::ASCII.GetBytes($credValue)
   }

   Write-Host "[+] This is the first key which will be added to this service principal" -ForegroundColor Cyan
   Update-MgServicePrincipal -ServicePrincipalId $p.Id -KeyCredentials $params
}

  3. Execute o script do PowerShell criado na etapa anterior. Por exemplo:

    .\UploadAuthCert.ps1

  4. Depois de iniciar o script, uma caixa de diálogo de credenciais é exibida. Introduza as credenciais da conta de administrador inquilino na sua organização Microsoft Online Microsoft Entra. Depois de executar o script, deixe o Windows PowerShell ligado à sessão do Microsoft Graph aberta. Você usará isso para executar um script do PowerShell na próxima etapa.

Passo 5: Registar todas as autoridades de nome de anfitrião para os pontos finais http do Exchange no local internos e externos com o ID do Microsoft Entra

Tem de executar o script neste passo para cada ponto final acessível publicamente na sua organização do Exchange no local, incluindo URLs Internos e Externos para Autenticação Moderna Híbrida). Por exemplo, se o Exchange estiver disponível externamente em https://mail.contoso.com/ews/exchange.asmx, utilize o nome https://mail.contoso.comdo principal de serviço . Não há um limite para o registro de outras autoridades de nome de host externas.

Para confirmar os pontos finais do Exchange na sua organização no local, execute os seguintes comandos na Shell de Gestão do Exchange:

Get-MapiVirtualDirectory | Format-List server,*url*
Get-WebServicesVirtualDirectory | Format-List server,*url*
Get-OABVirtualDirectory | Format-List server,*url*

Observação

O script seguinte requer que o Windows PowerShell ligado ao Microsoft Graph esteja ligado à sua organização do Microsoft 365, conforme explicado no passo 4 da secção anterior.

  1. Salve o texto a seguir em um arquivo de script do PowerShell chamado, por exemplo, de RegisterEndpoints.ps1. Substitua https://mail.contoso.com/ e https://autodiscover.contoso.com/ pela autoridade de nome de anfitrião adequada para a sua organização do Exchange no local.

     $ServiceName = "00000002-0000-0ff1-ce00-000000000000";
 $x = Get-MgServicePrincipal -Filter "AppId eq '$ServiceName'"
 $x.ServicePrincipalNames += "https://mail.contoso.com/"
 $x.ServicePrincipalNames += "https://autodiscover.contoso.com/"
 Update-MgServicePrincipal -ServicePrincipalId $x.Id -ServicePrincipalNames $x.ServicePrincipalNames

  2. No Windows PowerShell ligado ao Microsoft Graph, execute o script do Windows PowerShell que criou no passo anterior. Por exemplo:

    .\RegisterEndpoints.ps1

  3. Para verificar se todos os registos foram adicionados, execute o seguinte comando no Windows PowerShell ligado ao Microsoft Graph e procure https://namespace entradas nos resultados.

    Get-MgServicePrincipal -Filter "AppId eq '$ServiceName'" | Select-Object -ExpandProperty ServicePrincipalNames | Sort-Object

Passo 6: Criar um IntraOrganizationConnector da sua organização no local para o Microsoft 365 ou o Office 365

Neste passo, configuramos um IntraOrganizationConnector que permite que o Exchange Server no local chegue à sua organização do Exchange Online. Este conector permite a disponibilidade de funcionalidades e a conectividade do serviço em todas as organizações. Pode utilizar o cmdlet Get-IntraOrganizationConfiguration nos seus inquilinos no local e no Microsoft 365 ou Office 365 para determinar os valores de ponto final necessários para o cmdlet New-IntraOrganizationConnector .

Configuramos o domínio de encaminhamento híbrido como endereço de destino. O domínio de encaminhamento híbrido é criado automaticamente quando a sua organização do Microsoft 365 ou Office 365 é criada. Por exemplo, se o primeiro domínio que foi adicionado e validado na organização do Microsoft 365 ou office 365 for contoso.com, o seu endereço de destino seria contoso.mail.onmicrosoft.com.

Usando o Exchange PowerShell, execute o seguinte cmdlet em sua organização local:

$ServiceDomain = (Get-AcceptedDomain | Where-Object {$_.DomainName -like "*.mail.onmicrosoft.com"}).DomainName.Address
New-IntraOrganizationConnector -Name ExchangeHybridOnPremisesToOnline -DiscoveryEndpoint https://outlook.office365.com/autodiscover/autodiscover.svc -TargetAddressDomains $ServiceDomain

Passo 7: Criar um IntraOrganizationConnector a partir da sua organização do Microsoft 365 ou do Office 365 para a sua organização do Exchange no local

Neste passo, configuramos um IntraOrganizationConnector que permite que o Exchange Online chegue à sua organização do Exchange no local. Este conector permite a disponibilidade de funcionalidades e a conectividade do serviço em todas as organizações. Pode utilizar o cmdlet Get-IntraOrganizationConfiguration nos seus inquilinos no local e no Microsoft 365 ou Office 365 para determinar os valores de ponto final necessários para o cmdlet New-IntraOrganizationConnector .

Deve adicionar todos os domínios SMTP que são utilizados na sua organização do Exchange no local (exceto o seu initial domain e hybrid routing domain) como TargetAddressDomains. Se tiver vários domínios SMTP, adicione-os como uma lista separada por vírgulas (por exemplo, contoso.com,tailspintoys.com). Também tem de fornecer o ponto final de Deteção Automática no local como DiscoveryEndpoint.

Depois de ligar ao PowerShell do Exchange Online, substitua <your on-premises AutoDiscover endpoint> e <your on-premises SMTP domain(s)> pelos seus valores e execute o seguinte comando:

New-IntraOrganizationConnector -Name ExchangeHybridOnlineToOnPremises -DiscoveryEndpoint <your on-premises AutoDiscover endpoint> -TargetAddressDomains <your on-premises SMTP domain(s)>

Etapa 8: Configure um AvailabilityAddressSpace para quaisquer servidores pré-Exchange 2013 SP1

Aviso

O Exchange Server 2007, o Exchange Server 2010 e o Exchange Server 2013 chegaram ao fim do suporte.

Quando configura uma implementação híbrida em organizações mais antigas do Exchange, precisa de, pelo menos, um servidor do Exchange 2013 com o Exchange 2013 SP1 ou posterior. O servidor do Exchange 2013 requer as funções de servidor de Acesso de Cliente e Caixa de Correio. O servidor do Exchange 2013 coordena as comunicações entre a sua organização existente do Exchange no local e a organização do Exchange Online. É altamente recomendada a instalação de mais de um servidor do Exchange 2013 em sua organização no local para ajudar a aumentar a confiabilidade e a disponibilidade dos recursos de implantação híbrida.

Nas organizações do Exchange 2013 com o Exchange 2010 ou o Exchange 2007, recomendamos que todos os servidores front-end com acesso à Internet sejam servidores de Acesso de Cliente do Exchange 2013 com SP1 ou posterior. Todos os pedidos dos Serviços Web Exchange (EWS) têm de passar por um servidor de Acesso de Cliente do Exchange 2013. Este requisito inclui pedidos do Microsoft 365 para a sua organização do Exchange no local e pedidos da sua organização do Exchange no local para o Microsoft 365. É importante que tenha servidores de Acesso de Cliente do Exchange 2013 suficientes para processar a carga de processamento e fornecer redundância de ligação. O número de servidores de Acesso de Cliente de que precisa depende da quantidade média de pedidos EWS e varia consoante a organização.

Antes de concluir esta etapa, verifique se:

  • Os servidores híbridos de front-end são o Exchange 2013 SP1 ou superior.
  • Você tem uma URL de EWS externa exclusiva para os servidores Exchange 2013. A organização do Microsoft 365 ou do Office 365 tem de se ligar a estes servidores para que os pedidos baseados na nuvem para funcionalidades híbridas funcionem corretamente.
  • Os servidores têm funções de servidor de Caixa de Correio e de Acesso para Cliente
  • Quaisquer servidores de Caixa de Correio e de Acesso para Cliente do Exchange 2010/2007 existentes têm a Atualização Cumulativa (CU) ou Service Pack (SP) mais recente aplicado.

Observação

Os servidores de Caixa de Correio do Exchange 2010/2007 podem continuar a usar os servidores de Acesso para Cliente do Exchange 2010/2007 para servidores Front-End para conexões de recursos não híbridos. Apenas os pedidos de funcionalidades de implementação híbrida da organização do Microsoft 365 ou do Office 365 precisam de se ligar aos servidores do Exchange 2013.

Tem AvailabilityAddressSpace de ser configurado em servidores de Acesso de Cliente pré-Exchange 2013 que apontem para o ponto final dos Serviços Web exchange do servidor(s) de Acesso de Cliente do Exchange 2013 SP1 no local. Esse ponto de extremidade é o mesmo ponto de extremidade descrito na Etapa 5 ou pode ser determinado executando o seguinte cmdlet em seu servidor local de Acesso para Cliente do Exchange 2013 SP1:

Get-WebServicesVirtualDirectory | Format-List AdminDisplayVersion,ExternalUrl

Observação

Se as informações de diretório virtual forem retornadas de vários servidores, use o ponto de extremidade retornado para um servidor de Acesso para Cliente do Exchange 2013 SP1. Será apresentado 15.0 (Build 847.32) ou superior para o AdminDisplayVersion parâmetro .

Para configurar o , utilize o AvailabilityAddressSpaceExchange PowerShell e execute o seguinte cmdlet na sua organização no local:

Add-AvailabilityAddressSpace -AccessMethod InternalProxy -ProxyUrl <your on-premises external Exchange Web Services URL> -ForestName <your hybrid routing domain> -UseServiceAccount $true

Como saber se funcionou?

É possível verificar se a configuração do OAuth está correta usando o cmdlet Test-OAuthConnectivity. Este cmdlet verifica se os pontos finais do Exchange e do Exchange Online no local podem autenticar pedidos entre si com êxito.

Para verificar se a sua organização local do Exchange pode se conectar ao Exchange Online, execute o seguinte comando no Exchange PowerShell em sua organização local:

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

Para verificar se a sua organização do Exchange Online consegue ligar-se com êxito à sua organização do Exchange no local, ligue-se ao PowerShell do Exchange Online e execute o seguinte comando:

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

Exemplo:

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

Importante

Pode ignorar o The SMTP address has no mailbox associated with it. erro. Só é importante que o ResultTask parâmetro devolva um valor de Success. Por exemplo, a última secção do resultado do teste deve ler:

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