Поделиться через

Включение современной проверки подлинности в локальной среде Exchange

ПРИМЕНИМО К:no-img-162016 yes-img-192019 yes-img-seSubscription Edition

Обзор

Начиная с Exchange Server 2019 CU13, Exchange Server поддерживает OAuth 2.0 (также называется Modern Authentication) для локальных сред, использующих ADFS в качестве службы маркеров безопасности (STS). В этом документе приведены предварительные требования и шаги для включения этой функции.

Современную проверку подлинности в Exchange Server 2019 году не следует путать с гибридной современной проверкой подлинности (HMA), которая использует Microsoft Entra ID для современной проверки подлинности. На самом деле, HMA по-прежнему является рекомендуемым методом для включения современной проверки подлинности для всех локальных и облачных пользователей в гибридной конфигурации Exchange. Эта новая функция позволяет использовать современную проверку подлинности для организаций, которые не имеют Microsoft Entra ID или не находятся в гибридной конфигурации Exchange.

Как будет работать современная проверка подлинности и применима ли эта функция ко мне?

С помощью современной проверки подлинности пользователи могут проходить проверку подлинности в Exchange с помощью ADFS. Если для пользователя включена современная проверка подлинности, клиент Outlook перенаправляется в ADFS. Затем пользователи могут пройти проверку подлинности, предоставив учетные данные или выполнив многофакторную проверку подлинности. После проверки подлинности пользователя ADFS создает маркеры доступа. Exchange Server проверяет эти маркеры доступа для предоставления клиентского доступа к почтовому ящику пользователя.

На следующей схеме показана координация между Exchange Server, ADFS и Outlook для проверки подлинности пользователя с помощью современной проверки подлинности.

Схема, на которую показан рабочий процесс подтверждения Exchange Server современной проверки подлинности 2019 года. На предыдущей диаграмме шаги 3a, 4aи 5a6a происходят, когда для конечного пользователя включена современная проверка подлинности. Шаги 3bвыполняются 4b , когда современная проверка подлинности отключена для пользователя.

Ознакомьтесь со следующей таблицей, чтобы оценить, применима ли эта функция для вас.

Конфигурация Exchange Применима ли эта функция? Замечания
Локальная организация Exchange только с Exchange Server 2019 г. Да Н/Д
Локальная организация Exchange с сочетанием Exchange Server 2019, Exchange Server 2016 и Exchange Server 2013 Нет Exchange Server 2013 не поддерживается.
Локальная организация Exchange с сочетанием Exchange Server 2019 и Exchange Server 2016 Да В качестве серверов Front-End (клиентский доступ) можно использовать только серверы Exchange 2019.
Гибридная организация Exchange с использованием HMA Нет Предпочтительным решением является HMA с использованием Microsoft Entra ID. Ознакомьтесь с руководством по использованию новых политик проверки подлинности.
Гибридная организация Exchange без HMA Нет Используйте HMA с Microsoft Entra ID.

Предварительные требования для включения современной проверки подлинности в Exchange

Exchange Server 2019 CU13 или более поздней версии

Чтобы использовать современную проверку подлинности, все серверы, используемые для клиентских подключений, должны иметь Exchange Server 2019 с накопительным пакетом обновления 13 (CU13).

ADFS 2019 или более поздней версии

Чтобы включить современную проверку подлинности в локальной среде Exchange, требуется службы федерации Active Directory (AD FS) (ADFS) в Windows Server 2019 или более поздней версии. Установка и настройка роли ADFS на Exchange Server не поддерживается. Дополнительные сведения см. в статье Планирование топологии развертывания AD FS.

Для включения клиентского доступа извне корпоративной сети также может потребоваться веб-сервер Application Proxy (Windows Server 2019 г. или более поздней версии). Дополнительные сведения см. в разделе Настройка веб-Application Proxy можно настроить для доступа к экстрасети (необязательно).

Предварительные требования для клиента

Для использования современной проверки подлинности пользователям требуются клиентские приложения, такие как Outlook или другие собственные клиенты операционной системы, совместимые с современной проверкой подлинности через ADFS.

Outlook для Windows

Поддержка современной проверки подлинности через ADFS доступна в следующих версиях Microsoft Outlook for Windows. Клиент Microsoft Outlook Для Windows, начиная с номера 16.0.17628.10000сборки, использует последнюю версию MSAL library для проверки подлинности. Чтобы убедиться, что используется самый актуальный стек проверки подлинности, рекомендуется установить последнюю версию:

Outlook в Приложения Microsoft 365:

Канал Поддерживается Версия Сборка (или более поздняя версия)
Канал предварительной оценки Да 2304 16327.20200
Актуальный канал Да 2304 16327.20214
Ежемесячный канал (корпоративный) Да 2304 16327.20324
Полугодовой канал (предварительная корпоративная версия) Да 2402 17328.20184
Полугодовой канал (корпоративный) Да 2402 17328.20452

Outlook для Windows (корпоративная лицензия & розничной торговли):

Версия Поддерживается Версия Сборка (или более поздняя версия)
Outlook 2016 (любая версия) Нет Н/Д Н/Д
Outlook 2019 (любая версия) Нет Н/Д Н/Д
Outlook 2021 (розничная версия) Да 2304 16327.20214
Outlook 2021 (том) Нет Н/Д Н/Д
Outlook 2024 (розничная версия) Да 2410 18129.20158
Outlook 2024 (том) Да 2408 17932.20162

Вы можете проверка номер сборки Office, выполнив указанные здесь действия.

Outlook для Mac

Поддержка современной проверки подлинности через ADFS доступна в Outlook for Mac (Microsoft 365) Microsoft 365, начиная с номера 16.95.4 (25040241)сборки . Обратите внимание, что современная проверка подлинности через ADFS в настоящее время не поддерживается в автономных версиях, таких как Outlook 2024 for Mac.

ОС Windows

Клиент Windows должен быть Windows 11 22H2 or later установлен, и на нем должно быть установлено обновление от 14 марта 2023 г.

Вы можете просмотреть журнал клиентский компонент Центра обновления Windows, чтобы убедиться, что KB5023706 установлен.

Снимок экрана: журнал обновлений компьютера, работающего Windows 11 22H2.

Платформы Apple

Поддержка современной проверки подлинности через ADFS доступна в Apple Mail приложении, начиная с macOS Sequoia и iOS 17.6.1, а также начиная Outlook for Mac (Microsoft 365) с macOS Sequoia.

Протоколы, работающие с современной проверкой подлинности ADFS

В следующей таблице описаны протоколы, к которым можно получить доступ с помощью маркеров современной проверки подлинности ADFS. Мы постоянно работаем над добавлением поддержки современной проверки подлинности ADFS в более Exchange Server протоколы.

Протокол Поддержка современной проверки подлинности ADFS
MAPI через HTTP (MAPI/HTTP) Да
Outlook Anywhere (RPC/HTTP) Нет
Exchange Active Sync (EAS) Да
Веб-службы Exchange (EWS) Да
Outlook в Интернете (OWA) Да (проверка подлинности на основе утверждений)
Центр Администратор Exchange (ECP) Да (проверка подлинности на основе утверждений)
автономная адресная книга (OAB); Да
IMAP Нет
POP Нет

Действия по настройке современной проверки подлинности в Exchange Server с использованием ADFS в качестве службы stS

В этом разделе содержатся сведения о реализации современной проверки подлинности в Exchange Server 2019 с накопительным пакетом обновления 13 (CU13).

Установите Exchange 2019 с накопительным пакетом обновления 13 (CU13) на всех серверах FE (по крайней мере)

Все серверы, используемые для клиентских подключений, должны быть обновлены до Exchange 2019 с накопительным пакетом обновления 13 (CU13). Такой подход гарантирует, что начальные клиентские подключения к Exchange 2019 используют OAuth, а прокси-подключения для Exchange Server 2016 — Kerberos.

В Exchange 2019 CU13 добавлена поддержка новых политик проверки подлинности, позволяющих разрешить или заблокировать современную проверку подлинности на уровне пользователя. Блокировка современной проверки подлинности используется для обеспечения того, чтобы клиенты, которые не поддерживают современную проверку подлинности, по-прежнему могли подключаться.

Запуск /PrepareAD с программой установки требуется для добавления нескольких новых параметров политики проверки подлинности в Exchange Server.

  1. BlockModernAuthActiveSync
  2. BlockModernAuthAutodiscover
  3. BlockModernAuthImap
  4. BlockModernAuthMapi
  5. BlockModernAuthOfflineAddressBook
  6. BlockModernAuthPop
  7. BlockModernAuthRpc
  8. BlockModernAuthWebServices

После установки CU13 или более поздней версии все существующие политики проверки подлинности (включая политику проверки подлинности по умолчанию) отключат параметры. Это означает, что если вы уже используете HMA, вам не нужно изменять ранее существующие политики проверки подлинности.

Новая политика проверки подлинности для гибридного развертывания Exchange не требуется

Существующие гибридные конфигурации Exchange должны использовать гибридную современную проверку подлинности (HMA). Гибридные установки с использованием HMA могут оставить значения BlockModernAuth* параметров на уровне , 0 чтобы продолжить использование HMA. Действия, описанные по настройке современной проверки подлинности с помощью ADFS, актуальны только для организаций, которые не используют гибридную среду Exchange и являются исключительно локальными.

Настройка службы федерации Active Directory (AD FS) (ADFS)

Необходимо установить и настроить ADFS в среде, чтобы разрешить клиентам Exchange использовать проверку подлинности Forms (OAuth) для подключения к Exchange Server. Ознакомьтесь с контрольным списком: настройка сервера федерации , чтобы помочь в настройке ADFS.

Компонент ADFS можно установить, выполнив следующую команду в окне PowerShell с повышенными привилегиями на новом сервере, который становится сервером ADFS:

Install-WindowsFeature ADFS-Federation -IncludeManagementTools

Требования к сертификатам для конфигурации ADFS в организации Exchange Server

Для ADFS требуются два основных типа сертификатов (подробные сведения см. в этой статье ):

  1. Обмен данными между службами SSL-сертификатом для зашифрованного трафика веб-служб между сервером ADFS, клиентами, серверами Exchange и необязательным сервером веб-Application Proxy. Рекомендуется использовать сертификат, выданный внутренним или коммерческим центром сертификации (ЦС), так как все клиенты должны доверять этому сертификату.
  2. Сертификат подписи маркеров для зашифрованного обмена данными и проверки подлинности между сервером ADFS, контроллерами домена Active Directory и серверами Exchange. Вы можете получить сертификат подписи маркеров, запросив его в ЦС или создав самозаверяющий сертификат.

Дополнительные сведения о создании и импорте SSL-сертификатов в Windows см. в разделе Серверные сертификаты.

Ниже приведена сводка сертификатов, которые мы используем в этом сценарии:

Общее имя (CN) в сертификате (в поле Тема, Альтернативное имя субъекта или совпадение сертификата с подстановочными знаками) Тип Требуется на серверах Comments
adfs.contoso.com
enterpriseregistration.contoso.com		 Выдано ЦС Сервер ADFS,
Сервер веб-Application Proxy (необязательно)		 Серверы федерации используют SSL-сертификат для защиты трафика веб-служб для связи SSL с клиентами и прокси-серверами федерации.

Поскольку сертификат SSL должен быть доверенным для клиентских компьютеров, мы рекомендуем использовать сертификат, подписанный надежным центром сертификации. Все выбранные вами сертификаты должны иметь соответствующий закрытый ключ.
Подписывание маркера ADFS — adfs.contoso.com Самозаверяющий или проблема в ЦС Сервер ADFS,
Сервер веб-Application Proxy (необязательно)		 Сертификат подписи маркера — это сертификат X509. Серверы федерации используют связанные пары открытого и закрытого ключей для цифровой подписи всех создаваемых ими маркеров безопасности. Этот процесс включает подписывание опубликованных метаданных федерации и запросов на разрешение артефактов.

В оснастке "Управление ADFS" можно настроить несколько сертификатов подписи маркеров, чтобы разрешить переключение сертификатов, когда срок действия одного сертификата близок к истечении срока действия. По умолчанию все сертификаты в списке публикуются, но только основной сертификат подписи маркеров используется ADFS для подписывания маркеров. Все выбранные вами сертификаты должны иметь соответствующий закрытый ключ.

Вы можете получить сертификат подписи маркеров, запросив его в корпоративном ЦС или общедоступном ЦС или создав самозаверяющий сертификат.
mail.contoso.com
autodiscover.contoso.com		 Выдано ЦС Серверы Exchange,
Сервер веб-Application Proxy (необязательно)		 Этот сертификат является типичным сертификатом, который используется для шифрования внешних клиентских подключений к Outlook в Интернете (и другим службам Exchange). Дополнительные сведения см. в статье Требования к сертификатам для служб Exchange.

Развертывание и настройка сервера ADFS

Используйте Windows Server 2019 или более поздней версии для развертывания сервера ADFS. Выполните действия, описанные в статьях Развертывание сервера ADFS и Настройка и тестирование сервера ADFS . Убедитесь, что URL-адрес метаданных федерации можно получить в веб-браузере как с сервера Exchange Server, так и с одного клиентского компьютера.

В URL-адресе используется следующий синтаксис: https://<FederationServiceName>/federationmetadata/2007-06/federationmetadata.xml

Пример: https://adfs.contoso.com/federationmetadata/2007-06/federationmetadata.xml

Настройка метода проверки подлинности в ADFS

Чтобы использовать современную проверку подлинности в Outlook в Windows, необходимо настроить Primary Authentication Methods. Рекомендуется выбрать Forms Authentication как для , так Extranet и Intranetдля . Эту настройку можно выполнить, выполнив следующие команды из окна PowerShell на сервере ADFS:

Set-AdfsGlobalAuthenticationPolicy -PrimaryIntranetAuthenticationProvider FormsAuthentication
Set-AdfsGlobalAuthenticationPolicy -PrimaryExtranetAuthenticationProvider FormsAuthentication

Выбор подходящего времени существования единого входа

Выберите подходящее время существования единого Sign-On (SSO), чтобы конечным пользователям не требовалось часто выполнять повторную проверку подлинности. Чтобы проверить текущую конфигурацию времени существования единого входа, откройте новое окно PowerShell на сервере ADFS и выполните следующую команду:

Get-AdfsProperties | Format-List SsoLifetime, PersistentSsoLifetimeMins, KmsiLifetimeMins, DeviceUsageWindowInDays, KmsiEnabled, PersistentSsoEnabled, BrowserSsoEnabled

Используйте командлет Set-AdfsProperties , чтобы настроить соответствующие значения для SsoLifetime, PersistentSsoLifetimeMins, KmsiLifetimeMinsи DeviceUsageWindowInDays. Эти параметры следует настроить, чтобы включить единый вход и определить срок его действия. В зависимости от режима единого входа, например Keep Me Signed In (KMSI) или Device registration, также может потребоваться включить KsmiEnabled и PersistentSsoEnabled. Дополнительные сведения о едином входе ADFS см. в документации по параметрам AD FS 2016 Единый вход.

Настройка регистрации устройств в ADFS

Рекомендуется включить эту функцию Device Registration в ADFS, чтобы воспользоваться улучшенным интерфейсом единого входа. Чтобы включить Device Registration, выполните действия, описанные в документации по настройке сервера федерации с помощью службы регистрации устройств .

Затем выполните все действия по настройке Device Registration Service Discovery и Device Registration Discovery Server SSL certificate, как описано в документации по настройке регистрации устройств .

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

Убедитесь, что регистрация устройства настроена и проверка подлинности устройства включена, проверив Device Registration Overview. Этот шаг рекомендуется для сокращения количества запросов на проверку подлинности для пользователей и может помочь применить политики контроль доступа в ADFS.

Настройка KSMI в ADFS

Если вы предпочитаете не использовать Device Registration или не можете это сделать, вы можете включить эту функцию Keep Me Signed In . Затем ADFS создает постоянный файл cookie сразу после проверки подлинности пользователя, устраняя необходимость повторной проверки подлинности в последующих сеансах при условии, что файл cookie остается действительным.

Срок действия маркера обновления равен времени существования файла cookie постоянного единого входа для Keep me signed in. Постоянное время существования файла cookie единого входа по умолчанию составляет один день и не более семи дней. В противном случае время существования маркера обновления равно времени существования файла cookie единого входа сеанса (по умолчанию 8 часов). Дополнительные сведения о KSMI см. в документации по параметрам единого входа AD FS .

KMSI отключен по умолчанию и может быть включен, задав для свойства KmsiEnabled ADFS значение True. Обязательно выполните следующие действия в окне PowerShell на сервере ADFS:

Set-AdfsProperties -EnableKmsi $true

Если ПАРАМЕТР KMSI отключен, период единого входа по умолчанию — 8 hours. Период единого входа можно настроить с помощью свойства SsoLifetime. Свойство измеряется в минутах, поэтому его значение по умолчанию :480

Set-AdfsProperties -SsoLifetime <LifetimeInMinutes>

Если включено KMSI, период единого входа по умолчанию — 24 hours. Период единого входа с включенным KMSI можно настроить с помощью свойства KmsiLifetimeMins. Свойство измеряется в минутах, поэтому его значение по умолчанию :1440

Set-AdfsProperties -KmsiLifetimeMins <LifetimeInMinutes>

Создание группы приложений Outlook ADFS

Если вы впервые настраиваете современную проверку подлинности ADFS в локальной среде Exchange, выполните действия, описанные в этом разделе руководства. Если у вас есть конфигурация современной проверки подлинности ADFS, настроенная до поддержки клиентов, отличных Microsoft Outlook for Windowsот , см. действия, описанные в разделе Обновление существующей группы приложений Outlook ADFS этой документации. Следующие команды PowerShell должны выполняться из окна PowerShell на сервере ADFS. Если вы не планируете использовать приложения iOS и macOS, например собственное приложение Apple Mail, можно пропустить создание собственного клиентского приложения ADFS для iOS и macOS. Однако мы рекомендуем создавать их ради полноты.

Сначала мы создадим ADFS Application Group:

New-AdfsApplicationGroup -Name "Outlook" -ApplicationGroupIdentifier "Outlook" -Disabled:$false

Далее мы создадим еще Scopes - EAS.AccessAsUser.Allтри и : EWS.AccessAsUser.Alloffline_access

Add-AdfsScopeDescription -Name "EAS.AccessAsUser.All" -Description "EAS scope"
Add-AdfsScopeDescription -Name "EWS.AccessAsUser.All" -Description "EWS scope"
Add-AdfsScopeDescription -Name "offline_access" -Description "Offline Access"

Теперь мы создадим два Native Client Applications - Outlook - Native application и :iOS and macOS - Native mail application

Add-AdfsNativeClientApplication -Name "Outlook - Native application" -ApplicationGroupIdentifier "Outlook" -Identifier "d3590ed6-52b3-4102-aeff-aad2292ab01c" -RedirectUri @("ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c","msauth.com.microsoft.Outlook://auth","urn:ietf:wg:oauth:2.0:oob")
Add-AdfsNativeClientApplication -Name "iOS and macOS - Native mail application" -ApplicationGroupIdentifier "Outlook" -Identifier "f8d98a96-0999-43f5-8af3-69971c7bb423" -RedirectUri @("com.apple.mobilemail://oauth-redirect","com.apple.preferences.internetaccounts://oauth-redirect/","com.apple.Preferences://oauth-redirect/")

В качестве следующего шага мы создадим Web Api Applications. Мы создаем одно приложение для каждого URI, которое используется в среде Exchange Server. Если вы используете, например, autodiscover.contoso.com и mail.contoso.com, необходимо создать два Web Api Applications. Обязательно замените URI в следующем примере на URI, которые используются в настройке. Важно убедиться, что все URI для клиента охвачены. Включите конечный код / и убедитесь, что URI начинаются с https://:

# Replace the URIs with your URIs
$exchangeServerServiceFqdns = @("https://autodiscover.contoso.com/","https://mail.contoso.com/")

$issuanceTransformRules = @"
@RuleName = "ActiveDirectoryUserSID"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"]
 => issue(claim = c);

@RuleName = "ActiveDirectoryUPN"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
 => issue(claim = c);

@RuleName = "AppIDACR"
 => issue(Type = "appidacr", Value = "2");

@RuleName = "SCP"
 => issue(Type = "scp", Value = "user_impersonation");

@RuleName = "SCPEAS"
 => issue(Type = "scp", Value = "EAS.AccessAsUser.All");

@RuleName = "SCPEWS"
 => issue(Type = "scp", Value = "EWS.AccessAsUser.All");

@RuleName = "offlineaccess"
 => issue(Type = "scp", Value = "offline_access");
"@
foreach ($fqdn in $exchangeServerServiceFqdns) {
    Add-AdfsWebApiApplication -Name "Outlook - Web API ($((New-Guid).ToString("N")))" -ApplicationGroupIdentifier "Outlook" -Identifier $fqdn -IssuanceTransformRules $issuanceTransformRules -AccessControlPolicyName "Permit Everyone"
}

В качестве последнего шага мы добавим разрешения клиента для всех в Native Client Applications существующем Web Api Applications:

$clientRoleIdentifier = @("f8d98a96-0999-43f5-8af3-69971c7bb423","d3590ed6-52b3-4102-aeff-aad2292ab01c")
(Get-AdfsWebApiApplication -ApplicationGroupIdentifier "Outlook") | ForEach-Object {
    [string]$serverRoleIdentifier = $_.Identifier
    foreach ($id in $clientRoleIdentifier) {
        Grant-AdfsApplicationPermission -ClientRoleIdentifier $id -ServerRoleIdentifier $serverRoleIdentifier -ScopeNames "winhello_cert","email","profile","vpn_cert","logon_cert","user_impersonation","allatclaims","offline_access","EAS.AccessAsUser.All","EWS.AccessAsUser.All","openid","aza"
    }
}

Обновление существующей группы приложений Outlook ADFS

Важно!

Пропустите действия, описанные в этом разделе, если у вас нет существующей группы приложений Outlook ADFS, которая была настроена до поддержки клиентов, отличных Microsoft Outlook for Windows от появившегося.

Если у вас есть существующая конфигурация группы приложений Outlook ADFS, которая была настроена до поддержки клиентов, отличных Microsoft Outlook for Windows от появившегося, выполните приведенные здесь действия, чтобы включить поддержку других платформ. Следующие команды PowerShell должны выполняться из окна PowerShell на сервере ADFS.

Сначала мы создадим три дополнительных Scopes - EAS.AccessAsUser.Allи offline_accessEWS.AccessAsUser.All :

Add-AdfsScopeDescription -Name "EAS.AccessAsUser.All" -Description "EAS scope"
Add-AdfsScopeDescription -Name "EWS.AccessAsUser.All" -Description "EWS scope"
Add-AdfsScopeDescription -Name "offline_access" -Description "Offline Access"

Теперь мы создадим новый Native Client Applications - iOS and macOS - Native mail applicationобъект :

Add-AdfsNativeClientApplication -Name "iOS and macOS - Native mail application" -ApplicationGroupIdentifier "Outlook" -Identifier "f8d98a96-0999-43f5-8af3-69971c7bb423" -RedirectUri @("com.apple.mobilemail://oauth-redirect","com.apple.preferences.internetaccounts://oauth-redirect/","com.apple.Preferences://oauth-redirect/")

Мы обновляем существующий Native Client Application - Outlook - Native applicationобъект . Обязательно замените TargetName на целевое имя, которое вы используете в существующей конфигурации:

Set-AdfsNativeClientApplication -TargetName "Outlook - Native application" -RedirectUri @("ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c","msauth.com.microsoft.Outlook://auth","urn:ietf:wg:oauth:2.0:oob")

В качестве следующего шага необходимо создать по одному Web Api Application для каждого Identifier (URI), который используется в среде Exchange Server и существует в текущей конфигурации современной проверки подлинности ADFS:

$duplicateFqdnHashSet = New-Object System.Collections.Generic.HashSet[string]
$issuanceTransformRules = @"
@RuleName = "ActiveDirectoryUserSID"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"]
 => issue(claim = c);

@RuleName = "ActiveDirectoryUPN"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
 => issue(claim = c);

@RuleName = "AppIDACR"
 => issue(Type = "appidacr", Value = "2");

@RuleName = "SCP"
 => issue(Type = "scp", Value = "user_impersonation");

@RuleName = "SCPEAS"
 => issue(Type = "scp", Value = "EAS.AccessAsUser.All");

@RuleName = "SCPEWS"
 => issue(Type = "scp", Value = "EWS.AccessAsUser.All");

@RuleName = "offlineaccess"
 => issue(Type = "scp", Value = "offline_access");
"@
(Get-AdfsWebApiApplication -ApplicationGroupIdentifier "Outlook") | ForEach-Object {
    if ($_.Identifier.Count -gt 1) {
        Write-Host "[+] More than one identifier was found in Web Api Application: $($_.Name)" -ForegroundColor Yellow
        $_.Identifier | Select-Object -Skip 1 | ForEach-Object {
            Write-Host "[+] Identifier $_ must be added to a new Web Api Application and will now be removed from the existing one" -ForegroundColor Yellow
            [void]$duplicateFqdnHashSet.Add($_)
        }

        Set-AdfsWebApiApplication -TargetName $_.Name -Identifier ($_.Identifier)[0] -IssuanceTransformRules $issuanceTransformRules -AccessControlPolicyName "Permit Everyone"
    }
}

foreach($identifier in $duplicateFqdnHashSet) {
    Write-Host "[+] Creating a new Web Api Application for: $identifier" -ForegroundColor Yellow
    Add-AdfsWebApiApplication -Name "Outlook - Web API ($((New-Guid).ToString("N")))" -ApplicationGroupIdentifier "Outlook" -Identifier $identifier -IssuanceTransformRules $issuanceTransformRules -AccessControlPolicyName "Permit Everyone"
    Write-Host "[+] Done!`r`n" -ForegroundColor Green
}

В качестве последнего шага мы добавим разрешения клиента для всех в Native Client Applications существующем Web Api Applications:

$clientRoleIdentifier = @("f8d98a96-0999-43f5-8af3-69971c7bb423","d3590ed6-52b3-4102-aeff-aad2292ab01c")
$requiredScopes = @("winhello_cert","email","profile","vpn_cert","logon_cert","user_impersonation","allatclaims","offline_access","EAS.AccessAsUser.All","EWS.AccessAsUser.All","openid","aza")

(Get-AdfsWebApiApplication -ApplicationGroupIdentifier "Outlook") | ForEach-Object {
    [string]$serverRoleIdentifier = $_.Identifier
    Write-Host "[+] Processing Server Role: $serverRoleIdentifier" -ForegroundColor Yellow
    foreach ($id in $clientRoleIdentifier) {
        Write-Host "[+] Processing Client Role: $id" -ForegroundColor Yellow
        $permissionEntry = Get-AdfsApplicationPermission | Where-Object { $_.ClientRoleIdentifier -eq $id -and $_.ServerRoleIdentifier -eq $serverRoleIdentifier }
        if ($null -eq $permissionEntry) {
            Write-Host "[+] No Application Permission found for Client Role: $id - Server Role: $serverRoleIdentifier" -ForegroundColor Yellow
            Grant-AdfsApplicationPermission -ClientRoleIdentifier $id -ServerRoleIdentifier $serverRoleIdentifier -ScopeNames $requiredScopes
        } else {
            Write-Host "[+] Application Permission found - validating Scopes" -ForegroundColor Yellow
            $missingScopesList = New-Object System.Collections.Generic.List[string]
            $requiredScopes | ForEach-Object {
                if ($_ -in $permissionEntry.ScopeNames) {
                    Write-Host "[+] Scope: $_ is already set!" -ForegroundColor Green
                } else {
                    Write-Host "[+] Scope: $_ is missing and must be added" -ForegroundColor Yellow
                    $missingScopesList.Add($_)
                }
            }

            if ($missingScopesList.Count -ge 1) {
                Write-Host "[+] The following Scopes will be added: $([string]::Join(", ", $missingScopesList))" -ForegroundColor Yellow
                Set-AdfsApplicationPermission -TargetClientRoleIdentifier $id -TargetServerRoleIdentifier $serverRoleIdentifier -AddScope $missingScopesList
                Write-Host "[+] Done!`r`n" -ForegroundColor Green
            } else {
                Write-Host "[+] There is nothing to do!`r`n" -ForegroundColor Green
            }
        }
    }
}

Удаление существующей группы приложений Outlook ADFS

Предостережение

Выполнив действия, описанные в этом разделе, удаляется существующая конфигурация группы приложений Outlook ADFS.

Если у вас есть существующая конфигурация группы приложений Outlook ADFS и вы хотите удалить ее, выполните приведенные здесь действия, чтобы удалить существующую конфигурацию. Все следующие команды PowerShell должны выполняться из окна PowerShell на сервере ADFS.

Сначала мы удалим ADFS Application Group:

Remove-AdfsApplicationGroup -TargetApplicationGroupIdentifier "Outlook"

В качестве последнего шага мы удаляем добавленные пользовательские данные Scopes :

Remove-AdfsScopeDescription -TargetName "EAS.AccessAsUser.All"
Remove-AdfsScopeDescription -TargetName "EWS.AccessAsUser.All"
Remove-AdfsScopeDescription -TargetName "offline_access"

(Необязательно) Настроить веб-Application Proxy для доступа к экстрасети

Веб-Application Proxy является частью роли сервера удаленного доступа в Windows Server. Он предоставляет функции обратного прокси-сервера, позволяющие пользователям получать доступ к веб-приложениям за пределами корпоративной сети. Веб-Application Proxy предварительно выполняет проверку подлинности доступа к веб-приложениям с помощью ADFS и работает как прокси-сервер ADFS.

Если вы планируете использовать прокси-сервер веб-приложения, выполните действия, описанные в разделе Установка и настройка сервера веб-Application Proxy, чтобы настроить его. После настройки можно опубликовать правила для Autodiscover.contoso.com или и mail.contoso.com , выполнив действия, описанные в разделе Публикация приложения, использующего OAuth2.

(Необязательно) Настройка MFA для клиентского доступа

  1. Чтобы настроить ADFS с выбранным поставщиком MFA, ознакомьтесь со следующими ссылками.

  2. Настройте политику контроль доступа, требующую многофакторной проверки подлинности.

Создание политик проверки подлинности для конечных пользователей

Возможно, что не все пользователи в вашей организации имеют почтовые клиенты, поддерживающие современную проверку подлинности через ADFS. В этом сценарии рекомендуется включить современную проверку подлинности для пользователей с поддерживаемыми клиентами и заблокировать ее для пользователей без них.

Чтобы включить современную проверку подлинности для определенного набора пользователей и заблокировать ее для остальных пользователей, необходимо создать по крайней мере две политики проверки подлинности.

Важно!

Новые политики проверки подлинности становятся доступными сразу после подготовки Active Directory с помощью носителя Exchange 2019 CU13 или более поздней версии.

  • Политика всей организации для блокировки современной проверки подлинности по умолчанию
  • Вторичная политика для выборочного разрешения современной проверки подлинности для определенных пользователей

Следующие команды PowerShell должны выполняться из окна командной консоли Exchange (EMS) на сервере Exchange.

Создание политики на уровне организации для блокировки современной проверки подлинности по умолчанию

После включения современной проверки подлинности все клиенты Outlook пытаются использовать маркеры OAuth. Однако некоторые клиенты, несовместимые с современной проверкой подлинности ADFS, могут получать маркеры OAuth только из Microsoft Entra ID. Таким образом, эти клиенты не могут подключиться, если включена современная проверка подлинности.

Чтобы предотвратить этот сценарий, можно реализовать политику для всей организации, чтобы отключить современную проверку подлинности. В этом примере мы создадим новую политику проверки подлинности с именем Block Modern Auth.

New-AuthenticationPolicy "Block Modern Auth" -BlockModernAuthWebServices -BlockModernAuthActiveSync -BlockModernAuthAutodiscover -BlockModernAuthImap -BlockModernAuthMapi -BlockModernAuthOfflineAddressBook -BlockModernAuthPop -BlockModernAuthRpc

Эту политику можно задать на уровне организации с помощью следующей команды.

Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Modern Auth"

Создание политики проверки подлинности на уровне пользователя для включения современной проверки подлинности

Затем создайте вторую политику проверки подлинности, которая включает современную проверку подлинности. Назначьте эту политику всем пользователям с поддерживаемыми клиентами Outlook, чтобы разрешить их клиентам использовать современную проверку подлинности.

В этом примере мы создадим новую проверку подлинности с именем Allow Modern Auth с помощью следующей команды:

New-AuthenticationPolicy "Allow Modern Auth"

Настройка Exchange Server для использования маркеров OAuth ADFS

  1. Проверьте, включен ли OAuth параметр в следующих виртуальных каталогах. Если он не включен, включите OAuth его для всех этих виртуальных каталогов:

    Get-MapiVirtualDirectory | Format-List Server, *auth*
Get-WebServicesVirtualDirectory | Format-List Server, *auth*
Get-OabVirtualDirectory | Format-List Server, *auth*
Get-AutodiscoverVirtualDirectory | Format-List Server, *auth*
Get-ActiveSyncVirtualDirectory | Format-List Server, *auth*

    Выходные данные отображаются следующим образом. Основная деталь, на которой следует сосредоточиться, — это OAuth, как упоминалось ранее:

    Get-MapiVirtualDirectory | Format-List Server, *auth*

Server                        : EX1
IISAuthenticationMethods      : {Ntlm, OAuth, Negotiate}
InternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}
ExternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}

    Если OAuth на любом сервере или в любом из пяти виртуальных каталогов отсутствует, необходимо добавить его с помощью соответствующих команд, прежде чем продолжить: Set-MapiVirtualDirectory, Set-WebServicesVirtualDirectory, Set-OabVirtualDirectory, Set-AutodiscoverVirtualDirectory и Set-ActiveSyncVirtualDirectory.

  2. Выполните следующую команду:

    New-AuthServer -Type ADFS -Name MyADFSServer -AuthMetadataUrl https://<adfs server FQDN>/FederationMetadata/2007-06/FederationMetadata.xml

    Эта команда необходима для создания нового объекта сервера проверки подлинности в Exchange Server для ADFS. Объекты сервера проверки подлинности — это список доверенных издателей. Принимаются только маркеры OAuth от этих издателей.

  3. Выполните следующую команду:

    Set-AuthServer -Identity MyADFSServer -IsDefaultAuthorizationEndpoint $true

    Задайте сервер проверки подлинности, который мы только что добавили в DefaultAuthorizationEndpointкачестве . При рекламе заголовка Современной проверки подлинности Exchange Server объявляет URL-адрес проверки подлинности DefaultAuthorizationEndpoint. Таким образом клиенты узнают, какую конечную точку следует использовать для проверки подлинности.

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

    Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

  5. Включите современную проверку подлинности для пользователей с поддерживаемыми клиентами, назначив Allow Modern Auth политику проверки подлинности:

    Set-User -Identity User -AuthenticationPolicy "Allow Modern Auth"

Client-Side конфигурация современной проверки подлинности

Перед развертыванием для всех пользователей рекомендуется протестировать современную проверку подлинности с несколькими пользователями. После того как пилотная группа пользователей сможет использовать современную проверку подлинности, можно развернуть больше пользователей. Убедитесь, что клиент поддерживает современную проверку подлинности ADFS. Дополнительные сведения о поддерживаемых клиентах см. в разделе Предварительные требования для клиента .

Microsoft Windows

Включите современную проверку подлинности и добавьте домен ADFS в качестве доверенного домена в Outlook:

  1. Создайте следующие разделы реестра, чтобы сделать домен ADFS доверенным доменом. Обязательно добавьте оба ключа с и без в / конце домена ADFS:

    • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains\https://your-ADFS-domain/
    • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains\https://your-ADFS-domain

    Вы можете использовать PowerShell для создания разделов реестра или их развертывания с помощью групповая политика. Выполните следующие команды из окна PowerShell на каждом клиентском компьютере. Замените your-ADFS-domain доменом ADFS.

    New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains" -Force
(Get-Item HKLM:).OpenSubKey("SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains", $true).CreateSubKey("https://your-ADFS-domain/")
(Get-Item HKLM:).OpenSubKey("SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains", $true).CreateSubKey("https://your-ADFS-domain")

  2. Чтобы включить современную проверку подлинности ADFS, добавьте значение в Microsoft Outlook for WindowsEnableExchangeOnPremModernAuthREG_DWORD разделе .HKCU\SOFTWARE\Microsoft\Office\16.0\Common\Identity\

    С помощью PowerShell можно создать значение реестра или развернуть его с помощью групповая политика. Выполните следующую команду из окна PowerShell на каждом клиентском компьютере.

    Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Office\16.0\Common\Identity\" -Name "EnableExchangeOnPremModernAuth" -Value 1 -Type DWord

Apple macOS

Чтобы включить современную проверку подлинности для Microsoft Outlook в поддерживаемых версиях Apple macOS, необходимо изменить параметры для приложения Microsoft Outlook.

Откройте окно терминала и выполните следующую команду, заменив host1 полным доменным именем сервера ADFS. Убедитесь, что вы не включаете протокол и не добавляете косую черту в конец полного доменного имени. Например, если ваш сервер ADFS доступен через https://fs.contoso.com/, используйте fs.contoso.com. При наличии нескольких пространств имен ADFS добавьте их, разделенные пробелом.

defaults write com.microsoft.Outlook ADFSAuthorizedURLs -array host1

Для управляемых устройств администраторы могут использовать решение mobile Управление устройствами (MDM) для централизованного управления списком полных доменных имен ADFS и отправки на клиентские устройства. В следующей таблице описаны параметры конфигурации, необходимые для управления этой функцией с помощью MDM:

Параметры Значения
Целевое приложение Outlook Mac
Ключ конфигурации trustedauthorities
Тип значения String
Значение конфигурации <ADFS FQDNs>

Проверка потока современной проверки подлинности

После правильной настройки пользователи получают запрос на вход в ADFS при подключении к серверу Exchange Server.

Влияние на другие клиенты при включенной современной проверке подлинности

Пользователи, включенные для современной проверки подлинности, которые используют несколько клиентов (например, Outlook on Windows и Outlook Mobile), могут по-разному действовать в каждом клиенте. В приведенной ниже сводке описано поведение клиента при включенной современной проверке подлинности при условииDefaultAuthenticationPolicy, что Block Modern Auth она применяется в качестве на уровне организации.

Клиент Поведение
Outlook для Windows (классическая версия) По умолчанию использует современную проверку подлинности.
Outlook для Windows (новый) Пытается использовать современную проверку подлинности, но завершается сбоем.
Outlook для Mac Использует современную проверку подлинности, если она включена на клиенте.
Outlook iOS Возвращается к базовой проверке подлинности.
Outlook Android Возвращается к базовой проверке подлинности.
Почтовое приложение iOS Использует современную проверку подлинности.
Почтовое приложение macOS Использует современную проверку подлинности.
Приложение Gmail Возвращается к базовой проверке подлинности.
OWA/ECP Не использует политику проверки подлинности.
В зависимости от того, как она настроена, используется современная проверка подлинности или обычная проверка подлинности.
Приложение "Почта Windows" Не возвращается к базовой проверке подлинности.
Клиент Thunderbird Не возвращается к базовой проверке подлинности.
PowerShell Использует обычную проверку подлинности.

Влияние на OWA/ECP при включении современной проверки подлинности для других клиентов

Вы можете использовать проверку подлинности на основе утверждений ADFS для Outlook в Интернете. Указанные действия необходимы для включения OAuth для других клиентов и не влияют на настройку OWA/ECP.

Использование проверки подлинности на основе утверждений AD FS с Outlook в Интернете

Время ожидания после изменения политики проверки подлинности

После изменения политики проверки подлинности, чтобы разрешить современную проверку подлинности или заблокировать устаревшую проверку подлинности:

  • Подождите 30 минут, пока новые политики будут считываться внешними серверами

    или

  • Выполните сброс IIS на всех внешних серверах.

Переход на гибридную современную проверку подлинности после включения современной проверки подлинности для Exchange Server

Если вы используете современную проверку подлинности с ADFS, а затем решили настроить гибридную проверку подлинности Exchange, следует перейти на гибридную современную проверку подлинности. Подробные действия по миграции будут включены в будущую версию этого документа.

Обновление сертификатов

Оценка текущей конфигурации сертификата

Когда дело доходит до клиентских подключений к Exchange Server, сертификат, который должен быть оценен, является сертификатом, привязанным к интерфейсным сайту IIS. Для сервера ADFS идеально подходит проверка актуальности всех возвращенных Get-AdfsCertificate сертификатов.

  1. Чтобы определить соответствующий сертификат в Exchange Server, выполните следующие действия в командной консоли Exchange:

    Import-Module WebAdministration
(Get-ChildItem IIS:SSLBindings | Where-Object {($_.Sites -ne $null) -and ($_.Port -eq "443")}).Thumbprint | ForEach-Object {Get-ExchangeCertificate $_ | Where-Object {$_.Services -Match "IIS"} | Format-Table Thumbprint, Services, RootCAType, Status, NotAfter, Issuer -AutoSize -Wrap}

  2. Чтобы просмотреть активные сертификаты на сервере ADFS, выполните следующие действия в PowerShell:

    Get-AdfsCertificate | Format-Table CertificateType, Thumbprint, Certificate -AutoSize -Wrap

Обновление сертификатов в Exchange Server

Если выяснилось, что сертификат Exchange необходимо обновить для подключения клиента, необходимо выпустить новый сертификат и импортировать его на серверы Exchange. После этого сертификат должен быть как минимум включен для IIS. Оцените, должны ли быть включены другие службы для нового сертификата на основе вашей конфигурации.

Пример создания, завершения, включения и импорта нового сертификата на всех серверах на основе существующего сертификата в командной консоли Exchange:

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

    $txtrequest = Get-ExchangeCertificate <Thumbprint> | New-ExchangeCertificate -GenerateRequest -PrivateKeyExportable $true

  2. Создайте переменную, содержащую требуемый выходной путь для нового запроса на сертификат:

    $requestFile = "C:\temp\CertRequest.req"

  3. Создайте файл запроса сертификата:

    [System.IO.File]::WriteAllBytes($requestFile, [System.Text.Encoding]::Unicode.GetBytes($txtrequest))

    Примечание.

    Путь к папке для запроса сертификата уже должен существовать.

  4. Предоставление общего доступа к файлу запроса центру сертификации (ЦС). Действия, необходимые для получения завершенного сертификата, зависят от ЦС.

    Примечание.

    .p7b — предпочтительный формат для завершенного запроса.

  5. Создайте переменную, содержащую полный путь к завершенным запросам:

    $certFile = "C:\temp\ExchangeCert.p7b"

  6. Импортируйте запрос на сервер, который изначально создал запрос:

    Import-ExchangeCertificate -FileData ([System.IO.File]::ReadAllBytes($certFile)) -PrivateKeyExportable $true

  7. Переменная этапа для пароля для защиты завершенного сертификата:

    $pw = Read-Host "Enter password" -AsSecureString

  8. Экспортируйте двоичный файл сертификата в переменную:

    $binCert = Export-ExchangeCertificate <Thumbprint> -BinaryEncoded

  9. Переменная этапа для требуемого выходного пути завершенного сертификата:

    $certificate = "\\$env:computername\c$\temp\CompletedExchangeCert.pfx"

  10. Экспортируйте выполненный запрос для импорта на другие серверы:

    [System.IO.File]::WriteAllBytes($certificate, $binCert.FileData)

  11. Включите службы, которые должны быть привязаны к сертификату:

    Enable-ExchangeCertificate <Thumbprint> -Services IIS

    Примечание.

    Возможно, потребуется добавить дополнительные службы в предыдущий пример на основе предыдущей конфигурации сертификатов.

  12. Убедитесь, что сертификат работает должным образом, направив клиент на сервер для всех пространств имен клиента с файлом узла.

  13. Импортируйте сертификат Exchange на все остальные серверы Exchange:

    Import-ExchangeCertificate -PrivateKeyExportable $true -FileData ([System.IO.File]::ReadAllBytes($certificate)) -Password $pw -Server <Server-Name>

    Примечание.

    -PrivateKeyExportable Включение параметра является необязательным при импорте на другие серверы Exchange.

  14. Включите сертификат Exchange для необходимых служб Exchange на всех остальных серверах Exchange.

    Enable-ExchangeCertificate <Thumbprint> -Services IIS -Server <Server-Name>

    Примечание.

    Возможно, потребуется добавить дополнительные службы в предыдущий пример на основе предыдущей конфигурации сертификатов.

Обновление сертификата в ADFS

В зависимости от типа сертификата, который требует обновления в ADFS, определяет, нужно ли выполнять описанные ниже действия.

сертификат Service-Communications

В этом примере представлена оболочка PowerShell, необходимая для импорта сертификата в .pfx формате, например, созданном при выполнении действий по Exchange Server сертификату. Убедитесь, что вы вошли на основной сервер ADFS.

  1. Этап переменной, содержащей пароль для сертификата:

    $pw = Read-Host "Enter password" -AsSecureString

  2. Выполните этап переменной, содержащей полный путь к сертификату:

    $certificate = "\\E2k19-1\c$\temp\CompletedExchangeCert.pfx"

  3. Импортируйте сертификат в личное хранилище LocalMachine:

    Import-PfxCertificate -FilePath $certificate -CertStoreLocation Cert:\LocalMachine\my -Password $pw

  4. Обновите сертификат Service-Communications:

    Set-AdfsSslCertificate -Thumbprint <Thumbprint>

сертификаты Token-Signing и Token-Decryption

Выполните действия, описанные в документации по получению и настройке сертификатов TS и TD для AD FS .

Примечание.

Использование самозаверяющего сертификата по умолчанию для Token-Signing в проверке подлинности на основе утверждений ADFS для Outlook в Интернете требует установки сертификата на серверах Exchange Server.