Настройка проверки подлинности 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 после запуска мастера гибридной конфигурации.
Важно!
Если в вашей локальной организации работают только серверы Exchange 2013 с накопительным пакетом обновления 5 или более поздней версии, Exchange 2016 или Exchange 2019, запустите мастер гибридной конфигурации вместо выполнения действий, описанных в этом разделе.
Эта функция Exchange Server 2013 не полностью совместима с Office 365, предоставляемой компанией 21Vianet в Китае, и могут применяться некоторые ограничения. Дополнительные сведения см. в статье Office 365, управляемый 21Vianet.
Что нужно знать перед началом работы
Предполагаемое время выполнения задачи: 15 минут.
Для выполнения этой процедуры (процедур) необходимы соответствующие разрешения. Сведения о необходимых разрешениях см. в записи "Разрешения федерации и сертификатов" в разделе Разрешения инфраструктуры Exchange и оболочки .
Завершена настройка гибридного развертывания с помощью мастера гибридной конфигурации. Дополнительные сведения см. в разделе Гибридные развертывания Exchange Server.
Сочетания клавиш для процедур, описанных в этой статье, приведены в статье Сочетания клавиш в Центре администрирования Exchange.
Совет
Возникли проблемы? Обратитесь за помощью к участникам форумов Exchange. Посетите форумы в Exchange Server.
Настройка проверки подлинности OAuth между локальной организацией Exchange и Exchange Online
Глоссарий
Начальный домен: первый домен, подготовленный в клиенте. Например, contoso.onmicrosoft.com
. В этой документации он называется начальным< доменом> клиента.
Домен гибридной маршрутизации. Домен гибридной маршрутизации в гибридных средах Exchange, например contoso.mail.onmicrosoft.com
, используется для управления потоком почты между локальными серверами Exchange и Exchange Online. Это обеспечивает беспроблемную связь и доставку сообщений в обеих средах. В этой документации он называется <доменом> гибридной маршрутизации.
Адрес электронной почты Microsoft Online (MOERA) — адрес, созданный из префикса пользователя userPrincipalName
, а также начальный суффикс домена, который автоматически добавляется proxyAddress
в идентификатор Microsoft Entra. Например, 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 Server напрямую, чтобы экспортировать локальный сертификат авторизации, который затем импортируется в организацию Exchange Online на следующем шаге.
Сохраните следующий текст в файл сценария 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)
В командной консоли локальной организации 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" 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 }
Выполните сценарий PowerShell, созданный на предыдущем этапе. Например:
.\UploadAuthCert.ps1
После запуска сценария откроется диалоговое окно учетных данных. Введите учетные данные для учетной записи администратора клиента в организации 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*
Примечание.
Следующий сценарий требует, чтобы Windows PowerShell, подключенный к Microsoft Graph, был подключен к организации Microsoft 365, как описано на шаге 4 в предыдущем разделе.
Сохраните следующий текст в файл сценария 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
В Windows PowerShell, подключенной к Microsoft Graph, запустите сценарий Windows PowerShell, созданный на предыдущем шаге. Например:
.\RegisterEndpoints.ps1
Чтобы убедиться, что все записи добавлены, выполните следующую команду в 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 Server 2007, Exchange Server 2010 и Exchange Server 2013 закончилась.
При настройке гибридного развертывания в более старых организациях 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 (Build 847.32)
или выше для AdminDisplayVersion
параметра.
Чтобы настроить 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
Важно!
Эту ошибку The SMTP address has no mailbox associated with it.
можно игнорировать. Важно только, чтобы ResultTask
параметр возвращал значение Success
. Например, в последнем разделе выходных данных теста должно быть следующее:
ResultType: Success
Identity: Microsoft.Exchange.Security.OAuth.ValidationResultNodeId
IsValid: True
ObjectState: New