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

Применимо к: Exchange Server 2013Applies to: Exchange Server 2013

В гибридных развертываниях только с Exchange 2013 проверка подлинности OAuth настраивается с помощью мастера создания гибридной конфигурации. Для смешанных сред с Exchange 2013 и 2010 или Exchange 2013 и 2007 мастер создания гибридной конфигурации не настраивает новое гибридное подключение проверки подлинности OAuth между Office 365 и локальными организациями Exchange. Эти развертывания по умолчанию используют процесс доверия федерации. Однако определенные возможности Exchange 2013 полностью доступны в организации только при применении протокола проверки подлинности Exchange OAuth.Exchange 2013-only hybrid deployments configure OAuth authentication when using the Hybrid Configuration Wizard. For mixed Exchange 2013/2010 and Exchange 2013/2007 hybrid deployments, the new hybrid deployment OAuth-based authentication connection between Office 365 and on-premises Exchange organizations isn't configured by the Hybrid Configuration wizard. These deployments continue to use the federation trust process by default. However, certain Exchange 2013 features are only fully available across your organization by using the new Exchange OAuth authentication protocol.

В настоящее время новый процесс проверки подлинности Exchange OAuth позволяет использовать следующие возможности Exchange:The new Exchange OAuth authentication process currently enables the following Exchange features:

  • Управление записями сообщений (управления ЗАПИСЯМИ сообщений)Message Records Management (MRM)

  • функция Exchange "Обнаружение электронных данных на месте".Exchange In-place eDiscovery

  • архивация Exchange на месте.Exchange In-place Archiving

После настройки гибридного развертывания с помощью мастера гибридной конфигурации рекомендуется настроить во всех смешанных организациях Exchange, реализующих гибридное развертывание с Exchange 2013 и Exchange Online, проверку подлинности OAuth Exchange.We recommend that all mixed Exchange organizations that implement a hybrid deployment with Exchange 2013 and Exchange Online configure Exchange OAuth authentication after configuring their hybrid deployment with the Hybrid Configuration Wizard.

Важно!

Если в вашей локальной организации используются только серверы Exchange 2013 с накопительным пакетом обновления 5 или более поздней версией, запустите мастер гибридного развертывания вместо выполнения действий, описанных в этом разделе.If your on-premises organization is running only Exchange 2013 servers with Cumulative Update 5 or later installed, run the Hybrid Deployment Wizard instead of performing the steps in this topic.
Эта возможность Exchange Server 2013 не совместима полностью со службой Office 365, предоставляемой компанией 21Vianet в Китае. Кроме того, возможны некоторые ограничения. Дополнительные сведения о службе Office 365, предоставляемой компанией 21Vianet.This feature of Exchange Server 2013 isn't fully compatible with Office 365 operated by 21Vianet in China and some feature limitations may apply. For more information, see Learn about Office 365 operated by 21Vianet.

Что нужно знать перед началом работыWhat do you need to know before you begin?

Совет

Возникли проблемы?Having problems? Обратитесь за помощью к участникам форумов Exchange.Ask for help in the Exchange forums. Посетите форумы на сервере Exchange Server.Visit the forums at Exchange Server.

Настройка проверки подлинности OAuth между локальной организацией Exchange и Exchange OnlineHow do you configure OAuth authentication between your on-premises Exchange and Exchange Online organizations?

Шаг 1: создание объектов сервера авторизации для организации Exchange OnlineStep 1: Create the authorization server objects for your Exchange Online organization

Для этой процедуры необходимо указать проверенный домен для организации Exchange Online и имя клиента Exchange Online.For this procedure, you have to specify a verified domain for your Exchange Online organization and the Exchange Online Tenant Name. Первым доменом должен быть тот же домен, который использовался в качестве основного домена SMTP, используемого для облачных учетных записей электронной почты.The first domain should be the same domain used as the primary SMTP domain used for the cloud-based email accounts. Этот домен называется * <проверенным доменом> * в следующей процедуре.This domain is referred as <your verified domain> in the following procedure. Второй домен, который является именем реального клиента, например contoso.onmicrosoft.com, называется * <доменом>клиента*.The second domain which is your actual tenant name like contoso.onmicrosoft.com is referred to as <your tenant domain>.

Выполните следующую команду в командной консоли Exchange (Exchange PowerShell) в локальной организации Exchange:Run the following command in the Exchange Management Shell (Exchange PowerShell) in your on-premises Exchange organization:

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

Действие 2. Включение партнерского приложения для организации Exchange OnlineStep 2: Enable the partner application for your Exchange Online organization

Выполните следующую команду в командной консоли Exchange в своей локальной организации Exchange.Run the following command in the Exchange PowerShell in your on-premises Exchange organization.

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

Действие 3. Экспорт локального сертификата проверки подлинностиStep 3: Export the on-premises authorization certificate

На этом этапе необходимо выполнить сценарий PowerShell, чтобы экспортировать локальный сертификат проверки подлинности, который затем будет импортирован в вашу организацию Exchange Online.In this step, you have to run a PowerShell script to export the on-premises authorization certificate, which is then imported to your Exchange Online organization in the next step.

  1. Сохраните следующий текст в файл сценария PowerShell с именем ExportAuthCert.ps1.Save the following text to a PowerShell script file named, for example, 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)
    
  2. В командной консоли локальной организации Exchange выполните сценарий PowerShell, созданный на предыдущем этапе. Например:In Exchange PowerShell in your on-premises Exchange organization, run the PowerShell script that you created in the previous step. For example:

    .\ExportAuthCert.ps1
    

Шаг 4: отправка локального сертификата авторизации в службу контроля доступа Azure Active Directory (ACS)Step 4: Upload the on-premises authorization certificate to Azure Active Directory Access Control Service (ACS)

Затем вам нужно использовать Windows PowerShell, чтобы отправить локальный сертификат проверки подлинности, экспортированный на предыдущем этапе, в Служба контроля доступа Azure Active Directory.Next, you have to use Windows PowerShell to upload the on-premises authorization certificate that you exported in the previous step to Azure Active Directory Access Control Services (ACS). Для этого должны быть установлены командлеты Модуль Azure Active Directory для Windows PowerShell.To do this, the Azure Active Directory Module for Windows PowerShell cmdlets has to be installed. Если он не установлен, перейдите на страницу https://aka.ms/aadposh, чтобы установить Модуль Azure Active Directory для Windows PowerShell.If it's not installed, go to https://aka.ms/aadposh to install the Azure Active Directory Module for Windows PowerShell. После установки Модуль Azure Active Directory для Windows PowerShell выполните следующие действия.Complete the following steps after the Azure Active Directory Module for Windows PowerShell is installed.

  1. Щелкните ярлык Модуль Azure Active Directory для Windows PowerShell, чтобы открыть рабочее пространство Windows PowerShell с установленными командлетами Azure AD. Все команды на этом этапе выполняются с помощью Windows PowerShell для консоли Azure Active Directory.Click the Azure Active Directory Module for Windows PowerShell shortcut to open a Windows PowerShell workspace that has the Azure AD cmdlets installed. All commands in this step will be run using the Windows PowerShell for Azure Active Directory console.

  2. Сохраните следующий текст в файл сценария PowerShell с именем UploadAuthCert.ps1.Save the following text to a PowerShell script file named, for example, UploadAuthCert.ps1.

    Connect-MsolService
    $CertFile = "$env:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer"
    $objFSO = New-Object -ComObject Scripting.FileSystemObject
    $CertFile = $objFSO.GetAbsolutePathName($CertFile)
    $cer = New-Object System.Security.Cryptography.X509Certificates.X509Certificate
    $cer.Import($CertFile)
    $binCert = $cer.GetRawCertData()
    $credValue = [System.Convert]::ToBase64String($binCert)
    $ServiceName = "00000002-0000-0ff1-ce00-000000000000"
    $p = Get-MsolServicePrincipal -ServicePrincipalName $ServiceName
    New-MsolServicePrincipalCredential -AppPrincipalId $p.AppPrincipalId -Type asymmetric -Usage Verify -Value $credValue
    
  3. Выполните сценарий PowerShell, созданный на предыдущем этапе. Например:Run the PowerShell script that you created in the previous step. For example:

    .\UploadAuthCert.ps1
    
  4. После запуска сценария откроется диалоговое окно учетных данных. Введите данные учетной записи администратора клиента своей организации Microsoft Online Azure AD. После выполнения сценария оставьте сеанс Windows PowerShell для Azure AD открытым. Он понадобится для запуска сценария PowerShell на следующем этапе.After you start the script, a credentials dialog box is displayed. Enter the credentials for the tenant administrator account in your Microsoft Online Azure AD organization. After running the script, leave the Windows PowerShell for Azure AD session open. You will use this to run a PowerShell script in the next step.

Шаг 5: Зарегистрируйте все центры узлов для внутренней и внешней локальных конечных точек HTTP Exchange с помощью Azure Active Directory.Step 5: Register all hostname authorities for your internal and external on-premises Exchange HTTP endpoints with Azure Active Directory

Необходимо выполнить сценарий на этом шаге для каждой конечной точки в локальной организации Exchange, которая общедоступна (внутренние и внешние URL-адреса, если планируется настройка гибридной современной проверки подлинности).You have to run the script in this step for each endpoint in your on-premises Exchange organization that is publically accessible (Internal and External URLs if you are going to setup Hybrid Modern Authentication). Например, предположим, что сервер Exchange доступен для внешних пользователей по адресу https://mail.contoso.com/ews/exchange.asmx.For example, assume that Exchange is externally available on https://mail.contoso.com/ews/exchange.asmx. В этом случае используется имя участника службы: https://mail.contoso.com .In this case the service principal name of: https://mail.contoso.com would be used. Можно регистрировать неограниченное количество дополнительных служб внешних имен узлов.There isn't a limit for registering additional external hostname authorities.

Если вы не уверены в конечных точках Exchange в локальной организации Exchange, вы можете получить список внешних настроенных конечных точек веб-служб, выполнив следующую команду в Exchange PowerShell в локальной организации Exchange:If you are not sure of the Exchange endpoints in your on-premises Exchange organization, you can get a list of the external configured Web services endpoints by running the following command in Exchange PowerShell in your on-premises Exchange organization:

Get-MapiVirtualDirectory | FL server,*url*
Get-WebServicesVirtualDirectory | FL server,*url*
Get-OABVirtualDirectory | FL server,*url*

Примечание

Для успешного выполнения следующего сценария необходимо подключить Windows PowerShell для Azure Active Directory к своему клиенту Microsoft Online Azure AD, как описано в действии 4 предыдущего раздела.Successfully running the following script requires that the Windows PowerShell for Azure Active Directory is connected to your Microsoft Online Azure AD tenant, as explained in step 4 in the previous section.

  1. Сохраните следующий текст в файл сценария PowerShell с именем RegisterEndpoints.ps1.Save the following text to a PowerShell script file named, for example, RegisterEndpoints.ps1. В этом примере используется объект contoso.com.This example uses a contoso.com. https://mail.contoso.com/ & Замените https://autodiscover.contoso.com/ соответствующим центром узла для локальной организации Exchange.Replace https://mail.contoso.com/ & https://autodiscover.contoso.com/ with the appropriate hostname authority for your on-premises Exchange organization.

    $ServiceName = "00000002-0000-0ff1-ce00-000000000000";
    $x = Get-MsolServicePrincipal -AppPrincipalId $ServiceName;
    $x.ServicePrincipalnames.Add("https://mail.contoso.com/");
    $x.ServicePrincipalnames.Add("https://autodiscover.contoso.com/");
    Set-MSOLServicePrincipal -AppPrincipalId $ServiceName -ServicePrincipalNames $x.ServicePrincipalNames;
    
  2. В Windows PowerShell для Azure Active Directory выполните сценарий PowerShell, созданный на предыдущем этапе.In Windows PowerShell for Azure Active Directory, run the Windows PowerShell script that you created in the previous step. Например:For example:

    .\RegisterEndpoints.ps1
    
  3. Чтобы убедиться, что были добавлены все записи, необходимо выполнить следующее.To verify that all the records were added we need to run the following. Мы ищем https://namespace записи для всех записей URL-адресов, а не 00000002-0000-0ff1-ce00-000000000000/Namespace.We’re looking for https://namespace entries for all the URL’s, not 00000002-0000-0ff1-ce00-000000000000/namespace entries.

    Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 | select -ExpandProperty ServicePrincipalNames
    

Действие 6. Создание соединителя IntraOrganizationConnector локальной организации со службой Office 365Step 6: Create an IntraOrganizationConnector from your on-premises organization to Office 365

Необходимо определить целевой адрес ваших почтовых ящиков, размещенных в Exchange Online. Этот целевой адрес создается автоматически в процессе создания клиента Office 365. Например, если доменом вашей организации, размещенным в клиенте Office 365, является "contoso.com", то ваш целевой адрес службы — "contoso.mail.onmicrosoft.com".You must define a target address for your mailboxes that are hosted in Exchange Online. This target address is created automatically when your Office 365 tenant is created. For example, if your organization's domain hosted in the Office 365 tenant is "contoso.com", your target service address would be "contoso.mail.onmicrosoft.com".

С помощью Exchange PowerShell выполните следующий командлет в своей локальной организации:Using Exchange PowerShell, run the following cmdlet in your on-premises organization:

$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 клиента Office 365 с локальной организацией ExchangeStep 7: Create an IntraOrganizationConnector from your Office 365 tenant to your on-premises Exchange organization

Необходимо определить целевой адрес ваших почтовых ящиков, размещенных в локальной организации.You must define a target address for your mailboxes that are hosted in your on-premises organization. Если основным SMTP-адресом организации является "contoso.com", то ваш целевой адрес — "contoso.com".If you organization's primary SMTP adddress is "contoso.com", this would be "contoso.com". Кроме того, необходимо определить внешнюю точку автообнаружения для локальной организации.You must also define the external Autodiscover endpoint for your on-premises organization. Если ваша компания — "contoso.com", нужно использовать одно из следующих значений:If your company is "contoso.com" this is usually either of the following:

  • https://autodiscover.<yourваш основой домен SMTP>/autodiscover/autodiscover.svchttps://autodiscover.<your primary SMTP domain>/autodiscover/autodiscover.svc

  • https://<ваш основной домен SMTP>/autodiscover/autodiscover.svchttps://<your primary SMTP domain>/autodiscover/autodiscover.svc

Примечание

Командлет Get-IntraOrganizationConfiguration можно использовать для локальных клиентов и клиентов Office 365 для определения значений конечных точек, необходимых для командлета New-IntraOrganizationConnector.You can use the Get-IntraOrganizationConfiguration cmdlet in both your on-premises and Office 365 tenants to determine the endpoint values needed by New-IntraOrganizationConnector cmdlet.

С помощью Windows PowerShell выполните следующий командлет:Using Windows PowerShell, run the following cmdlet:

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session
New-IntraOrganizationConnector -name ExchangeHybridOnlineToOnPremises -DiscoveryEndpoint <your on-premises Autodiscover endpoint> -TargetAddressDomains <your on-premises SMTP domain>

Действие 8. Настройка AvailabilityAddressSpace для любых серверов Exchange до версии Exchange 2013 с пакетом обновления 1 (SP1)Step 8: Configure an AvailabilityAddressSpace for any pre-Exchange 2013 SP1 servers

При настройке гибридного развертывания в организации с версией Exchange, предшествующей Exchange 2013, необходимо установить в существующей организации Exchange по крайней мере один сервер Exchange 2013 SP1 или более поздней версии с ролями сервера клиентского доступа и сервера почтовых ящиков. Серверы клиентского доступа и почтовых ящиков Exchange 2013 действуют как интерфейсные серверы и управляют взаимодействием между существующей локальной организацией Exchange и организацией Exchange Online. Это взаимодействие включает в себя функции транспорта сообщений и обмена ими между локальной организацией и организацией Exchange Online. Мы настоятельно рекомендуем устанавливать в локальной организации более одного сервера Exchange 2013, чтобы повысить надежность и доступность компонентов гибридного развертывания.When you configure a hybrid deployment in a pre-Exchange 2013 organization, you have to install at least one Exchange 2013 SP1 or greater server with the Client Access and Mailbox server roles in your existing Exchange organization. The Exchange 2013 Client Access and Mailbox servers serve as frontend servers and coordinate communications between your existing Exchange on-premises organization and the Exchange Online organization. This communication includes message transport and messaging features between the on-premises and Exchange Online organizations. We highly recommend installing more than one Exchange 2013 server in your on-premises organization to help increase reliability and availability of hybrid deployment features.

В смешанном развертывании с Exchange 2013 и 2010 или Exchange 2013 и 2007 рекомендуется, чтобы все интерфейсные серверы, доступные из Интернета, для вашей организации были серверами клиентского доступа под управлением Exchange 2013 SP1 или более поздней версии. Все запросы веб-служб Exchange (EWS) из Office 365 и Exchange Online должны подключаться к серверам клиентского доступа Exchange 2013 в локальном развертывании. Кроме того, все запросы EWS из локальных организаций Exchange для Exchange Online должны пересылаться через сервер клиентского доступа с Exchange 2013 SP1 или более поздней версией. Так как эти серверы клиентского доступа Exchange 2013 должны обрабатывать дополнительные входящие и исходящие запросы EWS, важно использовать достаточно серверов клиентского доступа Exchange 2013 для обработки нагрузки и обеспечения избыточности подключений. Необходимое число серверов клиентского доступа зависит от среднего объема запросов EWS и в различных организациях разное.In a mixed deployment with Exchange 2013/2010 or Exchange 2013/2007, it is recommended that all the Internet-facing frontend servers for your on-premises organization are Client Access servers running Exchange 2013 SP1 or greater. All Exchange Web Services (EWS) requests originating from Office 365 and Exchange Online must connect to an Exchange 2013 Client Access server(s) in your on-premises deployment. Additionally, all EWS requests originating in your on-premises Exchange organizations for Exchange Online must be proxied through a Client Access server running Exchange 2013 SP1 or greater. Since these Exchange 2013 Client Access servers have to handle this additional incoming and outgoing EWS requests, it is important to have a sufficient number of Exchange 2013 Client Access servers available to handle the processing load and provide connection redundancy. The number of Client Access servers needed will depend on the average amount of EWS requests and will vary by organization.

Перед выполнением следующего действия убедитесь в следующем:Before you complete the following step, make sure:

  • Интерфейсные гибридные серверы работают под управлением Exchange 2013 SP1 или более поздней версии.The frontend hybrid servers are Exchange 2013 SP1 or greater

  • У вас есть уникальный внешний URL-адрес EWS для серверов Exchange 2013. Клиент Office 365 должен подключаться к этим серверам для правильной работы облачных запросов гибридных функций.You have a unique external EWS URL for the Exchange 2013 server(s). The Office 365 tenant must connect to these servers in order for cloud-based requests for hybrid features to work correctly.

  • На серверах используются роли сервера клиентского доступа и почтовых ящиков.The servers have both the Mailbox and Client Access server roles

  • На всех существующих серверах почтовых ящиков и клиентского доступа Exchange 2010 и 2007 установлены последние накопительные пакеты обновлений (CU) или пакеты обновлений (SP).Any existing Exchange 2010/2007 Mailbox and Client Access servers have the latest Cumulative Update (CU) or Service Pack (SP) applied.

Примечание

Существующие серверы почтовых ящиков Exchange 2010 или 2007 могут продолжать использовать серверы клиентского доступа Exchange 2010 и 2007 для интерфейсных серверов с негибридными подключениями. Только запросам компонентов гибридного развертывания от клиента Office 365 необходимо подключаться к серверам Exchange 2013.Existing Exchange 2010/2007 Mailbox servers can continue to use Exchange 2010/2007 Client Access servers for frontend servers for non-hybrid feature connections. Only hybrid deployment feature requests from the Office 365 tenant need to connect to Exchange 2013 servers.

AvailabilityAddressSpace необходимо настроить на серверах клиентского доступа до Exchange 2013, указывающие на конечную точку веб-служб Exchange для локальных серверов клиентского доступа Exchange 2013 с пакетом обновления 1 (SP1).An AvailabilityAddressSpace must be configured on pre-Exchange 2013 Client Access servers that points to the Exchange Web Services endpoint of your on-premises Exchange 2013 SP1 Client Access server(s). Используется конечная точка, описанная выше на шаге 5, либо ее можно определить, выполнив указанный ниже командлет на локальном сервере клиентского доступа Exchange 2013 с пакетом обновления 1 (SP1).This endpoint is the same endpoint as previously outlined in Step 5 or can be determined by running the following cmdlet on your on-premises Exchange 2013 SP1 Client Access server:

Get-WebServicesVirtualDirectory | Format-List AdminDisplayVersion,ExternalUrl

Примечание

Если сведения о виртуальных каталогах возвращается от нескольких серверов, используйте конечную точку, полученную для сервера клиентского доступа Exchange 2013 SP1.If virtual directory information is returned from multiple servers, make sure you use the endpoint returned for an Exchange 2013 SP1 Client Access server. Для параметра AdminDisplayVersion будет отображаться 15,0 (сборка 847,32) или выше.It will display 15.0 (Build 847.32) or higher for the AdminDisplayVersion parameter.

Чтобы настроить AvailabilityAddressSpace, с помощью Exchange PowerShell выполните приведенный ниже командлет в своей локальной организации.To configure the AvailabilityAddressSpace, use Exchange PowerShell and run the following cmdlet in your on-premises organization:

Add-AvailabilityAddressSpace -AccessMethod InternalProxy -ProxyUrl <your on-premises External Web Services URL> -ForestName <your Office 365 service target address> -UseServiceAccount $True

Как проверить, все ли получилось?How do you know this worked?

Проверить правильность конфигурации OAuth можно с помощью командлета Test-OAuthConnectivity. Этот командлет проверяет, могут ли конечные точки локальной организации Exchange и Exchange Online обмениваться запросами на проверку подлинности.You can verify that the OAuth configuration is correct by using the Test-OAuthConnectivity cmdlet. This cmdlet verifies that the on-premises Exchange and Exchange Online endpoints can successful authenticate requests from each other.

Важно!

При подключении к организации Exchange Online с помощью удаленной консоли PowerShell может потребоваться использовать параметр алловклоббер с командлетом Import-PSSession , чтобы импортировать последние команды в локальный сеанс PowerShell.When connecting to your Exchange Online organization using Remote PowerShell, you may have to use the AllowClobber parameter with the Import-PSSession cmdlet to import the latest commands in to the local PowerShell session.

Чтобы убедиться, что локальная организация Exchange может успешно подключиться к Exchange Online, выполните следующую команду в Exchange PowerShell в своей локальной организации:To verify that your on-premises Exchange organization can successfully connect to Exchange Online, run the following command in Exchange PowerShell in your on-premises organization:

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

Чтобы убедиться, что организация Exchange Online может успешно подключиться к локальной организации Exchange, воспользуйтесь сеансом удаленной среды Remote PowerShell, чтобы подключиться к своей организации Exchange Online и выполнить следующую команду:To verify that your Exchange Online organization can successfully connect to your on-premises Exchange organization, use the Remote PowerShell to connect to your Exchange Online organization and run the following command:

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 — ListSo, as an example, Test-OAuthConnectivity -Service EWS -TargetUri https://mail.contoso.com/metadata/json/1 -Mailbox ExchangeOnlineBox1 -Verbose | Format-List

Важно!

Вы можете пропустить параметр "SMTP-адрес не имеет связанных с ним почтовых ящиков".You can ignore the "The SMTP address has no mailbox associated with it." ошибкой.error. Очень важно, чтобы параметр ресулттаск возвращал значение Success.It's only important that the ResultTask parameter returns a value of Success. Например, в последнем разделе тестового результата должны быть следующие сведения:For example, the last section of the test output should read:
ResultType: Success
Identity: Microsoft.Exchange.Security.OAuth.ValidationResultNodeId
IsValid: True
ObjectState: New

Совет

Возникли проблемы? Попросите помощи на форумах Exchange. Перейти на форумы можно по следующей ссылке: Exchange Server.Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server.