Настройка проверки подлинности OAuth между организациями Exchange и Exchange Online

Мастер гибридной конфигурации автоматически настраивает проверку подлинности OAuth между локальной версией Exchange Server и организациями, использующими Exchange Online. Если организация Exchange содержит серверы Exchange 2010 или Exchange 2007, мастер гибридной конфигурации не настраивает проверку подлинности OAuth между локальной и сетевой организациями Exchange. Эти развертывания по умолчанию используют процесс доверия федерации. Однако некоторые функции полностью доступны в организации только при использовании нового протокола проверки подлинности Exchange OAuth.

В настоящее время новый процесс проверки подлинности Exchange OAuth позволяет использовать следующие возможности Exchange:

• Управление записями сообщений (MRM)
• функция Exchange "Обнаружение электронных данных на месте".
• архивация Exchange на месте.

Рекомендуем всем смешанным организациям Exchange 2013 настроить проверку подлинности Exchange OAuth после запуска мастера гибридной конфигурации.

Что нужно знать перед началом работы

• Предполагаемое время выполнения задачи: 15 минут.

• Для выполнения этой процедуры (процедур) необходимы соответствующие разрешения. Сведения о необходимых разрешениях см. в разделе "Разрешения инфраструктуры Exchange и оболочки" в разделе "Разрешения инфраструктуры Exchange и оболочки ".

• Завершена настройка гибридного развертывания с помощью мастера гибридной конфигурации. Дополнительные сведения см. в статье Гибридные развертывания Exchange Server.

• Сочетания клавиш для процедур, описанных в этой статье, приведены в статье Сочетания клавиш в Центре администрирования Exchange.

Настройка проверки подлинности OAuth между локальной организацией Exchange и Exchange Online

Глоссарий

Начальный домен: первый домен, подготовленный в клиенте. Например, contoso.onmicrosoft.com. В этой документации он называется <вашим начальным доменом> клиента.

Домен гибридной маршрутизации: домен гибридной маршрутизации в гибридных средах Exchange, например contoso.mail.onmicrosoft.com, используется для управления потоком почты между локальными серверами Exchange и Exchange Online. Это обеспечивает бесперебойную коммуникацию и доставку сообщений в обеих средах. В этой документации он называется доменом> гибридной< маршрутизации.

Microsoft Online Email Routing Address (MOERA): адрес, созданный на основе префикса userPrincipalName пользователя плюс начальный суффикс домена, который автоматически добавляется к proxyAddress Microsoft Entra ID. Например, smtp:john.doe@contoso.onmicrosoft.com. Мы не используем это слово MOERA в этой документации, но приводим его здесь для полноты картины.

Основной домен SMTP: основной домен SMTP на сервере Microsoft Exchange Server — это основной домен, используемый для адресов электронной почты в организации. В этой документации он называется <основным доменом> SMTP.

Конечная точка автообнаружения: Конечная точка автообнаружения — это URL-адрес веб-службы, предоставляющий сведения о конфигурации Exchange Server. Она позволяет приложениям автоматически обнаруживать службы Exchange и подключаться к ним. Если ваша организация использует, например, contoso.com в качестве основного домена SMTP, конечной точкой автообнаружения обычно https://autodiscover.contoso.com/autodiscover/autodiscover.svc является или https://contoso.com/autodiscover/autodiscover.svc. В этой документации она называется <локальной конечной точкой> автообнаружения.

Веб-службы Exchange (EWS): веб-службы Exchange (EWS) — это кроссплатформенный API, обеспечивающий приложениям доступ к таким элементам почтовых ящиков, как сообщения электронной почты, собрания и контакты. В этой документации он называется <URL-адресом> локальных внешних веб-служб Exchange.

Шаг 1. Создание объектов сервера авторизации для организации Exchange Online

Выполните следующую команду в командной консоли Exchange (Exchange PowerShell) в локальной организации Exchange. Перед запуском команды замените заполнители значениями:

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"

В GCC High или DoD вместо этого нужно использовать следующие команды:

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"

Действие 2. Включение партнерского приложения для организации Exchange Online

Выполните следующую команду в Exchange PowerShell в локальной организации Exchange:

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

Действие 3. Экспорт локального сертификата проверки подлинности

На этом этапе необходимо запустить скрипт PowerShell непосредственно на сервере Exchange для экспорта локального сертификата авторизации, который затем импортируется в вашу организацию Exchange Online на следующем шаге.

1. Сохраните следующий текст в файл сценария PowerShell с именем ExportAuthCert.ps1.

   Примечание.

   Если вы хотите отправить сертификат, который настроен на то, чтобы в будущем стать новым сертификатом проверки подлинности, замените $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. В командной консоли локальной организации Exchange выполните сценарий PowerShell, созданный на предыдущем этапе. Например, вы можете:

   .\ExportAuthCert.ps1
   

Шаг 4. Отправка локального сертификата авторизации в службу Microsoft Entra контроль доступа (ACS)

Затем с помощью Microsoft Graph PowerShell загрузите локальный сертификат авторизации, который вы экспортировали на предыдущем шаге, в службы Microsoft Entra контроль доступа (ACS). Если модуль не установлен, откройте окно Windows PowerShell от имени администратора и выполните следующую команду:

Install-Module -Name Microsoft.Graph.Applications

После установки Microsoft Graph PowerShell выполните следующие действия.

1. Откройте рабочую область Windows PowerShell, в которой установлены командлеты Microsoft Graph. Все команды на этом этапе будут выполняться с помощью Windows PowerShell, подключенного к консоли Microsoft Graph.

2. Сохраните следующий текст в файл сценария PowerShell с именем 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. Выполните сценарий PowerShell, созданный на предыдущем этапе. Например:

   .\UploadAuthCert.ps1
   

4. После запуска сценария откроется диалоговое окно учетных данных. Введите учетные данные для учетной записи администратора клиента в вашей организации Microsoft Online Microsoft Entra. После запуска скрипта оставьте сеанс Windows PowerShell, подключенный к Microsoft Graph, открытым. Он понадобится для запуска сценария PowerShell на следующем этапе.

Шаг 5. Регистрация всех центров имен узлов для внутренних и внешних конечных точек HTTP Exchange в локальной среде с помощью Microsoft Entra ID

На этом шаге необходимо запустить сценарий для каждой общедоступной конечной точки в локальной организации Exchange, включая внутренние и внешние URL-адреса для гибридной современной проверки подлинности. Например, если Exchange доступен извне по адресу https://mail.contoso.com/ews/exchange.asmx, используйте имя https://mail.contoso.comсубъекта-службы . Можно регистрировать неограниченное количество дополнительных служб внешних имен узлов.

Чтобы подтвердить конечные точки Exchange в локальной организации, выполните следующие команды командной консоли Exchange:

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

1. Сохраните следующий текст в файл сценария PowerShell с именем RegisterEndpoints.ps1. Замените https://mail.contoso.com/ и https://autodiscover.contoso.com/ используйте соответствующий центр имени узла для вашей локальной организации Exchange.

    $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. В Windows PowerShell, подключенном к Microsoft Graph, запустите сценарий Windows PowerShell, созданный на предыдущем шаге. Например, вы можете:

   .\RegisterEndpoints.ps1
   

3. Чтобы убедиться, что добавлены все записи, запустите следующую команду в Windows PowerShell, подключенном к Microsoft Graph, и найдите https://namespace записи в результатах.

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

Шаг 6. Создайте IntraOrganizationConnector из локальной организации в Microsoft 365 или Office 365

На этом шаге мы настраиваем сервер, IntraOrganizationConnector позволяющий локальному серверу Exchange Server связываться с вашей организацией Exchange Online. Этот соединитель обеспечивает доступность функций и подключение служб в организациях. Вы можете использовать командлет Get-IntraOrganizationConfiguration как в локальной среде, так и в клиентах Microsoft 365 или Office 365, чтобы определить значения конечных точек, необходимые командлету New-IntraOrganizationConnector.

Мы настраиваем домен гибридной маршрутизации в качестве целевого адреса. Домен гибридной маршрутизации создается автоматически при создании организации Microsoft 365 или Office 365. Например, если первым доменом, который был добавлен и проверен в организации Microsoft 365 или Office 365, является contoso.com, ваш целевой адрес будет contoso.mail.onmicrosoft.com.

С помощью Exchange PowerShell выполните следующий командлет в своей локальной организации:

$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

Шаг 7. Создайте IntraOrganizationConnector из организации Microsoft 365 или Office 365 в локальную организацию Exchange

На этом шаге мы настраиваем сервер, IntraOrganizationConnector позволяющий Exchange Online связываться с вашей локальной организацией Exchange. Этот соединитель обеспечивает доступность функций и подключение служб в организациях. Вы можете использовать командлет Get-IntraOrganizationConfiguration как в локальной среде, так и в клиентах Microsoft 365 или Office 365, чтобы определить значения конечных точек, необходимые командлету New-IntraOrganizationConnector.

Все домены SMTP, используемые в локальной организации Exchange (кроме вашей initial domain и hybrid routing domain), следует добавить в качестве TargetAddressDomainsдоменов . Если у вас несколько доменов SMTP, добавьте их в виде списка, разделенного запятыми (например, contoso.com,tailspintoys.com). Кроме того, необходимо указать локальную конечную точку автообнаружения как DiscoveryEndpoint.

Подключившись к Exchange Online PowerShell, замените <your on-premises AutoDiscover endpoint> и <your on-premises SMTP domain(s)> введите следующую команду:

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

Действие 8. Настройка AvailabilityAddressSpace для любых серверов Exchange до версии Exchange 2013 с пакетом обновления 1 (SP1)

При настройке гибридного развертывания в старых организациях Exchange требуется по крайней мере один сервер Exchange 2013 с пакетом обновления 1 (SP1) или более поздней версией. Для сервера Exchange 2013 необходимы роли сервера клиентского доступа и сервера почтовых ящиков. Сервер Exchange 2013 координирует взаимодействие между существующей локальной организацией Exchange и организацией Exchange Online. Мы настоятельно рекомендуем установить несколько серверов Exchange 2013 в локальной организации, чтобы повысить надежность и доступность функций гибридного развертывания.

В организациях, использующих Exchange 2013 или Exchange 2007, мы рекомендуем использовать в качестве серверов клиентского доступа Exchange 2013 серверы клиентского доступа Exchange 2013 с пакетом обновления 1 (SP1) или более поздней версии. Все запросы веб-служб Exchange (EWS) должны проходить через сервер клиентского доступа Exchange 2013. Это требование включает запросы из Microsoft 365 в локальную организацию Exchange и запросы из вашей локальной организации Exchange в Microsoft 365. Важно, чтобы серверов клиентского доступа Exchange 2013 было достаточно, чтобы справиться с нагрузкой и обеспечить избыточность подключений. Необходимое количество серверов клиентского доступа зависит от среднего объема запросов EWS и зависит от организации.

Перед выполнением следующего действия убедитесь в следующем:

• Гибридные серверы переднего плана — Exchange 2013 с пакетом обновления 1 (SP1) или более поздней версии.
• У вас есть уникальный внешний URL-адрес EWS для серверов Exchange 2013. Чтобы облачные запросы на гибридные функции работали правильно, организация Microsoft 365 или Office 365 должна подключиться к этим серверам.
• На серверах используются роли сервера клиентского доступа и почтовых ящиков.
• На всех существующих серверах почтовых ящиков и клиентского доступа Exchange 2010 и 2007 установлены последние накопительные пакеты обновлений (CU) или пакеты обновлений (SP).

На серверах клиентского доступа до Exchange 2013 необходимо настроить an AvailabilityAddressSpace и который указывает на конечную точку веб-служб Exchange локальных серверов клиентского доступа Exchange 2013 с пакетом обновления 1 (SP1). Используется конечная точка, описанная выше на шаге 5, либо ее можно определить, выполнив указанный ниже командлет на локальном сервере клиентского доступа Exchange 2013 с пакетом обновления 1 (SP1).

Get-WebServicesVirtualDirectory | Format-List AdminDisplayVersion,ExternalUrl

Чтобы настроить AvailabilityAddressSpace, используйте Exchange PowerShell и запустите следующий командлет в локальной организации:

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

Как проверить, все ли получилось?

Проверить правильность конфигурации OAuth можно с помощью командлета Test-OAuthConnectivity. Этот командлет проверяет, могут ли локальные конечные точки 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, подключитесь к PowerShell Exchange Online и выполните следующую команду:

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

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