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

  • Статья

Обзор

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

Для использования современной проверки подлинности пользователям требуются клиенты (Outlook или любые другие собственные клиенты ОС), поддерживающие современную проверку подлинности с помощью ADFS. Изначально эта функция доступна только для Outlook в Windows, но поддержка современной проверки подлинности будет добавлена в другие клиенты Outlook в будущем.

Современную проверку подлинности в Exchange Server 2019 году не следует путать с гибридной современной проверкой подлинности, которая использует 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, 5a и 6a происходят, когда для конечного пользователя включена современная проверка подлинности. Шаги 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 CU13.

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

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

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

Примечание.

Роль ADFS нельзя настроить на Exchange Server. Дополнительные сведения см. в статье Планирование топологии развертывания AD FS.

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

Outlook для Windows

Поддержка современной проверки подлинности через ADFS доступна в следующих версиях Microsoft Outlook.

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

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

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

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

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

Снимок экрана: номер сборки выпуска Outlook Приложения Microsoft 365.

Примечание.

Поддержка других клиентов, таких как Outlook для Mac, Outlook mobile, почтовое приложение iOS и т. д., будет добавлена позже.

ОС Windows

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

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

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

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

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

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

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

Примечание.

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

В 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 Hybrid должны использовать гибридную современную проверку подлинности. Гибридные клиенты, использующие HMA, могут оставить значения параметров BlockModernAuth* в 0, чтобы продолжить использовать HMA.

Примечание.

Приведенные ниже действия по настройке современной проверки подлинности с помощью ADFS применимы только для клиентов, не относящихся к Exchange Hybrid (чисто локально).

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

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

Требования к сертификатам для конфигурации 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. Серверы федерации используют связанные пары открытого и закрытого ключей для цифровой подписи всех создаваемых ими маркеров безопасности. Сюда входит подписывание опубликованных метаданных федерации и запросов на разрешение артефактов.

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

Вы можете получить сертификат подписи маркеров, запросив его в корпоративном ЦС или общедоступном ЦС или создав самозаверяющий сертификат.
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 на сервере ADFS и выберите Edit Federation Service Properties в разделе Действия (присутствует в правой части окна управления ADFS).

Снимок экрана: свойства времени существования единого входа ADFS.

Web SSO lifetime (minutes)Введите значение , которое является максимальным временем, по истечении которого пользователям необходимо повторно пройти проверку подлинности.

Снимок экрана: параметр времени существования единого входа ADFS в минутах.

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

Чтобы использовать современную проверку подлинности в Outlook в Windows, необходимо настроить основные методы проверки подлинности. Рекомендуется выбрать проверку подлинности Forms для экстрасети и интрасети, как показано ниже.

Снимок экрана: методы проверки подлинности ADFS.

Включение регистрации устройств в ADFS

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

Снимок экрана: страница обзора регистрации устройств ADFS.

Выполните все действия, чтобы настроить обнаружение службы регистрации устройств и SSL-сертификат сервера обнаружения регистрации устройств, как подробно [здесь](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn614658(v=ws.11).

Create группа приложений ADFS для Outlook

  1. Щелкните правой Application Groups кнопкой мыши и выберите .Add Application Group

    Снимок экрана: параметры ADFS. Отображается запрос контекстного меню. Выбран параметр Добавить группу приложений.

  2. Выберите .Native Application accessing a web API

  3. Введите имя, например, Outlook и нажмите кнопку Далее.

    Снимок экрана: помощник группы приложений

  4. В добавьте Native application pageследующие client identifier значения и redirect Uri для Outlook и нажмите кнопку Далее.

    • Идентификатор клиента: d3590ed6-52b3-4102-aeff-aad2292ab01c

    • URI перенаправления (добавьте следующие два URI):

      urn:ietf:wg:oauth:2.0:oob

      ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c

      Снимок экрана, на котором показаны собственные параметры приложения с именем Outlook.

  5. На вкладке Configure Web API добавьте все полные доменные имена, используемые средой Exchange, включая автообнаружение, полные доменные имена балансировки нагрузки, полные доменные имена сервера и т. д. Например:

    • https://autodiscover.contoso.com/
    • https://mail.contoso.com/

    Важно!

    Здесь важно убедиться, что все URL-адреса, доступные для клиента, покрыты, иначе они не будут работать. Включите конечные /s и убедитесь, что URL-адреса начинаются с https://.

    Снимок экрана: ADFS Добавление группы приложений помощник. На ней отображается страница для настройки веб-API.

  6. На вкладке Apply Access Control Policy Разрешить всем начать с, а затем изменить позже, если потребуется. Не проверка флажок в нижней части страницы.

  7. В Configure Application Permissionsвыберите Native Application appи в разделе Permitted Scopes проверка user_impersonation в дополнение к openid, который установлен по умолчанию.

    Снимок экрана: ADFS Добавление группы приложений помощник. На ней отображается страница для настройки разрешений приложения.

  8. Выполните помощник.

Добавление правил преобразования выдачи в группу приложений Outlook

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

Измените Web API settings, а в разделе Issuance Transform Rules добавьте следующие настраиваемые правила:

Снимок экрана: параметры приложения ADFS приложения с именем Outlook. Выбрана кнопка Изменить.

Имя правила утверждения Настраиваемое правило
ActiveDirectoryUserSID c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"] => issue(claim = c);
ActiveDirectoryUPN c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"] => issue(claim = c);
AppIDACR => issue(Type = "appidacr", Value = "2");
SCP => issue(Type = "http://schemas.microsoft.com/identity/claims/scope", Value ="user_impersonation");

После добавления правил Outlook - Web API Properties объект должен выглядеть следующим образом:

Снимок экрана: параметры приложения ADFS приложения с именем Outlook. Выбрана вкладка Правила преобразования выдачи.

При необходимости веб-Application Proxy можно настроить для доступа к экстрасети.

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

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

При необходимости MFA также можно настроить для клиентского доступа.

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

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

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

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

  1. Обновление клиента и ОС:

    Как описано в разделе Предварительные требования для клиента , современная проверка подлинности поддерживается только для Outlook в Windows. Чтобы использовать современную проверку подлинности, канал предварительной оценки клиента Outlook должен быть установлен на Windows 11 ОС 22H2 с обновлением от 14 марта 2023 г. или более поздней версии.

  2. Изменения реестра на клиентских компьютерах:

    Администраторам необходимо настроить значения реестра для пользователей.

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

    1. Добавьте следующие ключи, чтобы добавить домен ADFS в качестве доверенного домена:

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

      Примечание.

      Добавьте два ключа с и без "/" в конце домена ADFS.

      Снимок экрана: раздел реестра AuthTrustedDomains.

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

      Имя Значение
      EnableExchangeOnPremModernAuth 1

      Снимок экрана: раздел реестра удостоверений, расположенный в HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Common.

      Для упрощения развертывания эти изменения реестра можно настроить с помощью групповая политика. Если групповая политика не используется вашей организацией, пользователи должны настроить свой реестр вручную (или с помощью предоставленного вами скрипта).

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

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

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

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

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

После включения современной проверки подлинности все клиенты Outlook будут пытаться использовать маркеры OAuth, но некоторые клиенты (например, Outlook для Mac) могут получать маркеры 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"

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

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

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

New-AuthenticationPolicy "Allow Modern auth"

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

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

    Get-MapiVirtualDirectory -Server <ExchangeServerName> | Format-List *auth*

Get-WebServicesVirtualDirectory -Server <ExchangeServerName> | Format-List *auth*

Get-OabVirtualDirectory -Server <ExchangeServerName> | Format-List *auth*

Get-AutodiscoverVirtualDirectory -Server <ExchangeServerName> | Format-List *auth*

  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"

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

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

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

Пользователи, включенные для современной проверки подлинности с несколькими клиентами (например, Outlook для Windows и Outlook Mobile), будут иметь разные возможности для каждого клиента. Ниже приведена сводка по поведению клиентов при включенной современной проверке подлинности.

Примечание.

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

Клиент Поведение
Outlook в Windows (новые версии) По умолчанию использует современную проверку подлинности.
Outlook в Windows (старые версии) Попытается использовать современную проверку подлинности, но завершится ошибкой.
Outlook Mac Попытается использовать современную проверку подлинности, но завершится ошибкой; поддержка, пришедщая позже.
Outlook iOS Вернется к базовой проверке подлинности.
Outlook Android Вернется к базовой проверке подлинности.
Почтовое приложение iOS Вернется к базовой проверке подлинности.
Приложение 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 Server. После этого сертификат должен быть как минимум включен для IIS. Оцените, должны ли быть включены другие службы для нового сертификата на основе вашей конфигурации.

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

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

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

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

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

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

    [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.