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

Статья
04/09/2024

Область применения: Exchange Server 2013 г.

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

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

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

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

Важно!

Если в вашей локальной организации используются только серверы Exchange 2013 с накопительным пакетом обновления 5 или более поздней версией, запустите мастер гибридного развертывания вместо выполнения действий, описанных в этом разделе.
Эта функция Exchange Server 2013 не полностью совместима с Office 365, эксплуатируемой компанией 21Vianet в Китае, и могут применяться некоторые ограничения. Дополнительные сведения см. в разделе Office 365, управляемых 21Vianet.

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

Предполагаемое время выполнения задачи: 15 минут.
Для выполнения этой процедуры (процедур) необходимы соответствующие разрешения. Сведения о необходимых разрешениях см. в записи "Разрешения федерации и сертификатов" в разделе Разрешения инфраструктуры Exchange и оболочки .
Выполненная настройка гибридного развертывания с помощью мастера гибридного развертывания. Дополнительные сведения см. в разделе Exchange Server гибридных развертываний.
Сочетания клавиш для процедур, описанных в этой статье, приведены в статье Сочетания клавиш в Центре администрирования Exchange.

Совет

Возникли проблемы? Обратитесь за помощью к участникам форумов Exchange. Посетите форумы по адресу Exchange Server.

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

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

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

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

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.

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

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

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

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

$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)

В командной консоли локальной организации 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.

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

Сохраните следующий текст в файл сценария 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"
 $p = Get-MgServicePrincipal -Filter "AppId eq '$ServiceName'"
 $params = @{
 	keyCredentials = @{
 		type = "AsymmetricX509Cert"
 		usage = "Verify"
 		key = $credValue
 	}
 }
 Update-MgServicePrincipal -ServicePrincipalId $p.Id -BodyParameter $params

Выполните сценарий PowerShell, созданный на предыдущем этапе. Например:
```
.\UploadAuthCert.ps1
```
После запуска сценария откроется диалоговое окно учетных данных. Введите учетные данные для учетной записи администратора клиента в организации 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 | FL server,*url*
Get-WebServicesVirtualDirectory | FL server,*url*
Get-OABVirtualDirectory | FL server,*url*

Примечание.

Следующий сценарий требует, чтобы Windows PowerShell, подключенный к Microsoft Graph, был подключен к организации Microsoft 365, как описано на шаге 4 в предыдущем разделе.

Сохраните следующий текст в файл сценария PowerShell с именем RegisterEndpoints.ps1. В этом примере используется contoso.com. Замените https://mail.contoso.com/ и https://autodiscover.contoso.com/ соответствующим центром имени узла для локальной организации Exchange.
```
 $ServiceName = "00000002-0000-0ff1-ce00-000000000000";
 $x = Get-MgServicePrincipal -Filter "AppId eq '$ServiceName'"
 $ServicePrincipalUpdate =@(
    "https://mail.contoso.com/","https://autodiscover.contoso.com/"
 )
 Update-MgServicePrincipal -ServicePrincipalId $x.Id -ServicePrincipalNames $ServicePrincipalUpdate
```
В Windows PowerShell подключен к Microsoft Graph запустите скрипт Windows PowerShell, созданный на предыдущем шаге. Например:
```
.\RegisterEndpoints.ps1
```
Чтобы убедиться, что все записи добавлены, выполните следующую команду в Windows PowerShell подключены к Microsoft Graph и найдите https://namespace записи в результатах.
```
Get-MgServicePrincipal -Filter "AppId eq '$ServiceName'" | 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 выполните следующий командлет в своей локальной организации:

$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. Создание IntraOrganizationConnector из microsoft 365 или Office 365 организации в локальную организацию 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>

Примечание.

Командлет Get-IntraOrganizationConfiguration можно использовать как в локальной среде, так и в клиентах Microsoft 365 или Office 365, чтобы определить значения конечных точек, необходимые командлету New-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. Настройка 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).

Примечание.

Существующие серверы почтовых ящиков Exchange 2010 или 2007 могут продолжать использовать серверы клиентского доступа Exchange 2010 и 2007 для интерфейсных серверов с негибридными подключениями. К серверам Exchange 2013 должны подключаться только запросы функций гибридного развертывания от Microsoft 365 или Office 365 организации.

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

Get-WebServicesVirtualDirectory | Format-List AdminDisplayVersion,ExternalUrl

Примечание.

Если сведения о виртуальных каталогах возвращается от нескольких серверов, используйте конечную точку, полученную для сервера клиентского доступа Exchange 2013 SP1. Он будет отображать 15.0 (сборка 847.32) или более поздней версии для параметра AdminDisplayVersion .

Чтобы настроить 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

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

Проверить правильность конфигурации 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

Важно!

Вы можете игнорировать ошибку "SMTP-адрес не связан с почтовым ящиком". Важно только, чтобы параметр ResultTask возвращал значение Success. Например, в последнем разделе выходных данных теста должно быть следующее:

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

Совет

Возникли проблемы? Обратитесь за помощью к участникам форумов Exchange. Посетите форумы по адресу Exchange Server.

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительные ресурсы