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

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

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

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

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

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

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

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

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

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

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

Глоссарий

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

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

Адрес электронной почты Microsoft Online (MOERA) — адрес, созданный из префикса пользователя userPrincipalName , а также начальный суффикс домена, который автоматически добавляется proxyAddress в идентификатор Microsoft Entra. Например, smtp:[email protected]. Мы не используем в 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 Server напрямую, чтобы экспортировать локальный сертификат авторизации, который затем импортируется в организацию 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

На этом шаге необходимо запустить скрипт для каждой общедоступной конечной точки в локальной организации 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 под управлением Exchange 2013 с пакетом обновления 1 (SP1) или более поздней версии. Для сервера Exchange 2013 требуются роли сервера клиентского доступа и сервера почтовых ящиков. Сервер Exchange 2013 координирует обмен данными между существующей локальной организацией Exchange и организацией Exchange Online. Мы настоятельно рекомендуем установить несколько серверов Exchange 2013 в локальной организации, чтобы повысить надежность и доступность функций гибридного развертывания.

В организациях Exchange 2013 с Exchange 2010 или Exchange 2007 мы рекомендовали, чтобы все внешние серверы с выходом в Интернет были серверами клиентского доступа 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).

AvailabilityAddressSpace Необходимо настроить на серверах клиентского доступа до Exchange 2013, которые указывают на конечную точку веб-служб 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, подключитесь к 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