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


Настройка расширенной защиты Windows в Exchange Server

Обзор

Расширенная защита Windows улучшает существующую проверку подлинности в Windows Server и устраняет атаки ретранслятора проверки подлинности или атаки "человек в середине" (MitM). Для устранения рисков используются сведения о безопасности, реализованные с помощью сведений о привязке каналов, указанных в объекте Channel Binding Token (CBT) , который в основном используется для подключений TLS.

Расширенная защита включена по умолчанию при установке Exchange Server 2019 CU14 (или более поздней версии). Дополнительные сведения см. в статье Выпущено накопительное обновление H1 2024 для Exchange Server.

В более ранних версиях Exchange Server (например, Exchange Server 2016) расширенную защиту можно включить с помощью сценария ExchangeExtendedProtectionManagement.ps1 на некоторых или всех серверах Exchange.

Терминология, используемая в этой документации

Виртуальный каталог или vDir

Используется Exchange Server для предоставления доступа к веб-приложениям, таким как Exchange ActiveSync, Outlook on the Webи AutoDiscover службе. Администратор может настроить несколько параметров виртуального каталога, включая параметры проверки подлинности, безопасности и отчетов. Расширенная защита является одним из таких параметров проверки подлинности.

Параметр расширенной защиты

Управляет поведением для проверки Channel Binding Tokens или CBT. Возможные значения для этого параметра перечислены в следующей таблице:

Значение Описание
Нет Указывает, что службы IIS не выполняют проверку CBT.
Разрешить Указывает, что проверка CBT включена, но не является обязательной. Этот параметр обеспечивает безопасный обмен данными с клиентами, поддерживающими расширенную защиту, и по-прежнему поддерживает клиенты, которые не могут использовать расширенную защиту.
Обязательность Это значение указывает, что требуется проверка CBT. Этот параметр блокирует клиенты, которые не поддерживают расширенную защиту.

Флаги SSL

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

Разгрузка SSL

Завершает подключение на устройстве между клиентом и Exchange Server, а затем использует незашифрованное подключение для подключения к Exchange Server.

Мост SSL

Описывает процесс, в котором устройство, расположенное на границе сети, расшифровывает SSL-трафик, а затем повторно шифрует его перед отправкой на веб-сервер.

Современный гибридный или гибридный агент

Это имя метода настройки гибридной среды Exchange, который устраняет некоторые требования к конфигурации для классической гибридной среды (например, входящие сетевые подключения через брандмауэр) для включения гибридных функций Exchange. Дополнительные сведения об этой функции см. здесь.

Общедоступные папки

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

Предварительные требования для включения расширенной защиты в Exchange Server

Совет

Рекомендуется запустить скрипт средства проверки работоспособности Exchange Server , чтобы проверить, выполнены ли все предварительные требования на сервере Exchange Server, на котором должна быть активирована расширенная защита.

Версии Exchange Server, поддерживающие расширенную защиту

Расширенная защита поддерживается в Exchange Server 2013, 2016 и 2019, начиная с выпусков обновления для системы безопасности Exchange Server (SU) за август 2022 г.

Если в вашей организации установлен Exchange Server 2016 или Exchange Server 2019, на них должны быть установлены ежеквартальные обновления Exchange за сентябрь 2021 г. или накопительное обновление 2022 H1. Прежде чем продолжить настройку расширенной защиты, необходимо установить по крайней мере обновление системы безопасности за август 2022 г. или более поздней версии.

Если в вашей организации установлен Exchange Server 2013, exchange Server должен быть в накопительном пакете обновления 23 (CU23 ) с установленным обновлением для системы безопасности за август 2022 г. или более поздней версии.

Предупреждение

Поддержка Exchange Server 2013закончилась 11 апреля 2023 г.

Требования к конфигурации Outlook Anywhere

Разгрузка SSL для Outlook Anywhere включена по умолчанию и должна быть отключена перед включением расширенной защиты. Выполните действия, описанные в примере 3.

Важно!

Установщик Exchange Server 2019 CU14 (или более поздней версии) автоматически отключает разгрузку Outlook Anywhere SSL. Это часть расширенной защиты, включенной по умолчанию.

Требования к версии NTLM

NTLMv1 является слабым и не обеспечивает защиту от атак "человек в середине" (MitM). Ее следует рассматривать как уязвимую и больше не использовать.

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

Примечание.

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

Если после включения расширенной защиты клиенты получают запросы паролей, проверьте следующий раздел реестра и значение на клиенте и на стороне Exchange Server:

Раздел реестра: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

Значение реестра: LmCompatibilityLevel

Рекомендуется задать для него значение , равное 5Send NTLMv2 response only. Refuse LM & NTLM. Ему должно быть присвоено по крайней мере значение , для которого 3 задано значение Send NTLMv2 response only.

При удалении значения операционная система применяет системное значение по умолчанию. В Windows Server 2008 R2 и более поздних версиях мы обрабатываем его так, как если бы для него задано значение 3.

Если вы хотите централизованно управлять параметром, это можно сделать с помощью групповой политики:

Расположение политики: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Дополнительные сведения см. в статье Безопасность сети: уровень проверки подлинности LAN Manager

Требования к TLS

Перед включением расширенной защиты необходимо убедиться, что все конфигурации TLS согласованы на всех серверах Exchange. Например, если один из серверов использует TLS 1.2, необходимо убедиться, что все серверы в организации настроены с помощью TLS 1.2. Любой вариант использования версии TLS на разных серверах может привести к сбою подключений клиента или сервера к серверу.

В дополнение к этому требованию значение SchUseStrongCrypto реестра должно иметь значение на всех серверах 1 Exchange в организации.

Если для этого значения явно не задано 1значение , значение по умолчанию этого ключа можно интерпретировать как 0 или 1 в зависимости от версии .NET, используемой двоичными файлами Exchange Server, и существует вероятность возникновения проблем с подключением при обмене данными между сервером и сервером. Это может произойти, особенно если используются разные версии Exchange Server (например, Exchange Server 2016 и Exchange Server 2019).

То же самое относится и к значению SystemDefaultTlsVersions реестра, для которого также должно быть явно задано значение 1.

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

Сведения о настройке необходимых параметров TLS на серверах Exchange Server см. в этом руководстве по настройке TLS .

Совместимость стороннего программного обеспечения

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

Мы видели, например, антивирусные решения, которые отправляли подключения через локальный прокси-сервер для защиты клиентского компьютера. Такой сценарий будет препятствовать обмену данными с сервером Exchange Server и должен быть отключен, так как это считается подключением "человек в середине" (MitM), которое будет заблокировано расширенной защитой.

Сценарии, которые могут повлиять на подключение клиента при включенной расширенной защите

Сценарии разгрузки SSL

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

Сценарии мостов SSL

Расширенная защита поддерживается в средах, использующих мост ssl при определенных условиях. Чтобы включить расширенную защиту в среде Exchange с помощью МОСТА SSL, необходимо использовать один и тот же SSL-сертификат в Exchange и load Balancers. Использование разных сертификатов приводит к сбою проверки маркера привязки канала расширенной защиты и, как следствие, запрету подключения клиентов к серверу Exchange Server.

Сценарии расширенной защиты и общедоступных папок

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

Расширенная защита не может быть включена на серверах Exchange Server 2013 с общедоступными папками в среде сосуществования

Чтобы включить расширенную защиту в Exchange Server 2013, убедитесь, что у вас нет общедоступных папок, размещенных в Exchange Server 2013. Если у вас есть сосуществование Exchange Server 2013 с Exchange Server 2016 или Exchange Server 2019, перед включением расширенной защиты необходимо перенести общедоступные папки в Exchange Server 2016 или Exchange Server 2019. После включения расширенной защиты и появления общедоступных папок в Exchange Server 2013 они больше не будут отображаться для конечных пользователей!

Предупреждение

Поддержка Exchange Server 2013закончилась 11 апреля 2023 г.

Расширенная защита не может быть включена в Exchange Server 2016 CU22 или Exchange Server 2019 CU11 или более ранней версии, в которых размещена иерархия общедоступных папок.

Если у вас есть среда, содержащая Exchange Server 2016 CU22 или Exchange Server 2019 CU11 или более ранней версии, и вы используете общедоступные папки, перед включением расширенной защиты необходимо подтвердить версию сервера, на котором размещена иерархия общедоступных папок .

Убедитесь, что сервер, на котором размещена иерархия общедоступных папок, обновлен до Exchange Server 2016 CU23 или Exchange Server 2019 CU12 (или более поздней версии) с установленными последними обновлениями для системы безопасности . Переместите иерархию общедоступных папок на сервер Exchange Server, на котором выполняется требуемая версия, если не удается обновить сервер Exchange Server до поддерживаемой версии.

Для уточнения можно использовать следующую таблицу:

Версия Exchange Установлен накопительный пакет обновления Установленная единица хранения Размещает почтовые ящики PF Поддерживается ли EP?
Exchange 2013 CU23 Август 2022 г. (или более поздняя версия) Нет Да
Exchange 2016 CU22 Август 2022 г. (или более поздняя версия) Нет почтовых ящиков иерархии Да
Exchange 2016 CU23 (2022 H1) или более поздней версии Август 2022 г. (или более поздняя версия) Любой Да
Exchange 2019 CU11 Август 2022 г. (или более поздняя версия) Нет почтовых ящиков иерархии Да
Exchange 2019 CU12 (2022 H1) или более поздней версии Август 2022 г. (или более поздняя версия) Любой Да
Любая другая версия Любой другой cu Любой другой su Любой Нет

Расширенная защита и современная гибридная конфигурация

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

Расширенная защита не может быть полностью настроена на серверах Exchange Server, опубликованных с помощью гибридного агента

В современной гибридной конфигурации серверы Exchange публикуются через гибридный агент, который выполняет прокси-вызовы Exchange Online к серверу Exchange Server.

Включение расширенной защиты на серверах Exchange Server, опубликованных с помощью гибридного агента, может привести к нарушению гибридных функций, таких как перемещение почтовых ящиков и свободные и занятые вызовы, если они выполняются неправильно. Поэтому важно определить все серверы Exchange, опубликованные с помощью гибридного агента, и не включить расширенную защиту в Front-End виртуальном каталоге EWS на них.

Определение серверов Exchange, опубликованных с помощью гибридного агента

Если у вас нет списка серверов, опубликованных через гибридный агент, можно выполнить следующие действия, чтобы определить их. Эти действия не требуются, если вы используете классическое гибридное развертывание Exchange Server.

  1. Войдите на компьютер, на котором установлен гибридный агент, и откройте модуль PowerShell гибридного агента. Выполните команду Get-HybridApplication , чтобы определить, используемый TargetUri гибридным агентом.
  2. Параметр TargetUri предоставляет полное доменное имя сервера Exchange Server, который настроен для использования гибридным агентом.
    • Выведите удостоверение сервера Exchange с помощью полного доменного имени и запишите имя сервера Exchange.
    • Если вы используете URL-адрес Подсистемы балансировки нагрузки в TargetUri, необходимо определить все серверы Exchange, на которых Client Access установлена роль и доступ к которым можно получить за URL-адресом Load Balancer.

Важно!

Расширенная защита не должна быть включена в виртуальном каталоге Front-End EWS на серверах Exchange Server, опубликованных через гибридный агент.

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

Примечание.

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

  1. Для серверов Exchange, опубликованных через гибридный агент, входящие подключения должны быть ограничены брандмауэром, чтобы разрешить подключения только с компьютера, на котором установлен гибридный агент. Это не влияет на исходящие подключения с серверов Exchange Server к Exchange Online.
  2. Почтовые ящики не должны размещаться на серверах Exchange, опубликованных с помощью гибридного агента. Существующие почтовые ящики следует перенести на другие серверы почтовых ящиков.

Включение расширенной защиты

Расширенная защита автоматически включается во время установки Exchange Server 2019 CU14 (или более поздней версии). В более старых версиях Exchange Server, которые поддерживают расширенную защиту, ее можно включить с помощью сценария, предоставленного корпорацией Майкрософт (рекомендуется) или вручную с помощью диспетчера IIS.

Чтобы правильно настроить расширенную защиту, каждому виртуальному каталогу на всех серверах Exchange в организации (за исключением пограничных транспортных серверов) необходимо задать предписанное значение Extended Protection и sslFlags.

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

Веб-сайт IIS Виртуальный каталог Рекомендуемое значение Рекомендуемые sslFlags
Default Website API Required Ssl,Ssl128
Default Website AutoDiscover Off Ssl,Ssl128
Default Website ECP Required Ssl,Ssl128
Default Website EWS Accept (Пользовательский интерфейс) / Allow (Скрипт) Ssl,Ssl128
Default Website MAPI Required Ssl,Ssl128
Default Website Microsoft-Server-ActiveSync Accept (Пользовательский интерфейс) / Allow (Скрипт) Ssl,Ssl128
Default Website Microsoft-Server-ActiveSync/Proxy Accept (Пользовательский интерфейс) / Allow (Скрипт) Ssl,Ssl128
Default Website OAB Accept (Пользовательский интерфейс) / Allow (Скрипт) Ssl,Ssl128
Default Website OWA Required Ssl,Ssl128
Default Website PowerShell Off SslNegotiateCert
Default Website RPC Required Ssl,Ssl128
Exchange Backend API Required Ssl,Ssl128
Exchange Backend AutoDiscover Off Ssl,Ssl128
Exchange Backend ECP Required Ssl,Ssl128
Exchange Backend EWS Required Ssl,Ssl128
Exchange Backend Microsoft-Server-ActiveSync Required Ssl,Ssl128
Exchange Backend Microsoft-Server-ActiveSync/Proxy Required Ssl,Ssl128
Exchange Backend OAB Required Ssl,Ssl128
Exchange Backend OWA Required Ssl,Ssl128
Exchange Backend PowerShell Required Ssl,SslNegotiateCert,Ssl128
Exchange Backend RPC Required Ssl,Ssl128
Exchange Backend PushNotifications Required Ssl,Ssl128
Exchange Backend RPCWithCert Required Ssl,Ssl128
Exchange Backend MAPI/emsmdb Required Ssl,Ssl128
Exchange Backend MAPI/nspi Required Ssl,Ssl128

Примечание.

После первоначального выпуска мы обновили Default Website/OABAccept/AllowRequired значение вместо и Default Website/PowerShellOffRequiredвместо . Изменение в Default Website/OAB связано с тем, что клиенты Outlook для Mac больше не могут скачать автономную адресную книгу с параметром Required . Изменение заключается Default Website/PowerShell в том, что конфигурация Exchange Server по умолчанию не разрешает подключения с использованием проверки подлинности NTLM к PowerShell Front-End виртуальному каталогу, поэтому расширенная защита неприменима.

Внесение изменений в виртуальный Default Website/PowerShell каталог не поддерживается за исключением случаев, когда они явно не посоветуются службой поддержки и поддержкой майкрософт (CSS).

Включение расширенной защиты с помощью установщика Exchange Server 2019 CU14 (или более поздней версии)

При использовании Exchange Server 2019 CU14 и более поздних версий установщик Exchange Server 2019 с накопительным пакетом обновления (CU) автоматически включает расширенную защиту на сервере почтовых ящиков, где выполняется установка. Это происходит при любой новой установке или при обновлении существующей установки Exchange Server до последней версии.

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

Параметры можно использовать, чтобы пропустить автоматическую активацию расширенной защиты (/DoNotEnableEP) или не включить расширенную защиту в виртуальном каталоге Front-End EWS (/DoNotEnableEP_FEEWS).

Предупреждение

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

Сценарии конфигурации установщика расширенной защиты cu

В этом разделе мы рассмотрим наиболее распространенные сценарии настройки расширенной защиты на Exchange Server с помощью установщика Накопительного пакета обновления 14 (CU) для Exchange Server 2019 (или более поздней версии).

Убедитесь, что сервер Exchange Server настроен правильно и соответствует требованиям, описанным в разделе Предварительные требования для включения расширенной защиты на Сервере Exchange Server .

Сценарий 1. Включение расширенной защиты в Exchange Server 2019

Запустите настройку Exchange Server 2019 CU14 (или более поздней версии) в режиме с репликой или автоматическим. Установщик настроит расширенную защиту при установке сервера, на котором она была запущена.

Сценарий 2. Включение расширенной защиты в Exchange Server 2019, который публикуется с помощью гибридного агента

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

Запустите настройку Exchange Server 2019 CU14 (или более поздней версии) в автоматическом режиме с помощью /DoNotEnableEP_FEEWS параметра . Он пропускает включение расширенной защиты в виртуальном каталоге Front-End EWS:

<Virtual DVD drive letter>:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade /DoNotEnableEP_FEEWS
Сценарий 3. Пропуск включения расширенной защиты с помощью установки Exchange Server 2019 CU14 (или более поздней версии)

Запустите настройку Exchange Server 2019 CU14 (или более поздней версии) в автоматическом режиме с помощью /DoNotEnableEP параметра . Он пропускает включение расширенной защиты:

<Virtual DVD drive letter>:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade /DoNotEnableEP

Предупреждение

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

Включение расширенной защиты с помощью скрипта PowerShell

Вы можете использовать скрипт ExchangeExtendedProtectionManagement.ps1 , чтобы включить расширенную защиту на некоторых или всех серверах Exchange одновременно.

Важно!

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

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

Скрипт можно запустить на любом конкретном сервере Exchange Server в вашей среде, на котором установлена командная консоль Exchange (EMS).

Разрешения на настройку расширенной защиты с помощью скрипта PowerShell

Пользователь, который запускает скрипт, должен быть членом Organization Management группы ролей. Скрипт должен выполняться из командной консоли Exchange с повышенными привилегиями (EMS).

Сценарии конфигурации скриптов расширенной защиты

В этом разделе описаны наиболее распространенные сценарии настройки расширенной защиты в Exchange Server с помощью сценария PowerShellExchangeExtendedProtectionManagement.ps1 .

Дополнительные примеры и описание параметров скрипта см. в документации по скрипту .

Сценарий 1. Включение расширенной защиты на всех серверах Exchange Server

Запустите сценарий следующим образом, чтобы включить расширенную защиту на всех серверах Exchange в организации:

.\ExchangeExtendedProtectionManagement.ps1

Скрипт выполняет несколько проверок, чтобы убедиться, что все серверы Exchange имеют минимальную требуемую версию CU и SU для включения расширенной защиты. Он также проверяет, используют ли все серверы Exchange одну и ту же конфигурацию TLS.

После прохождения проверок предварительных требований скрипт включает расширенную защиту и добавляет необходимые ssl-флаги во все виртуальные каталоги всех серверов Exchange в области. Он останавливается, если сервер Exchange Server не выполняет требования (например, если обнаружена несогласованная конфигурация TLS).

Сценарий 2. Настройка расширенной защиты при запуске современной гибридной конфигурации

Если у вас есть современная гибридная конфигурация, необходимо пропустить включение расширенной защиты в виртуальном каталоге Front-End EWS на серверах Exchange Server, которые были опубликованы с помощью современного гибридного агента.

Эту настройку можно выполнить с помощью ExcludeVirtualDirectories параметра :

.\ExchangeExtendedProtectionManagement.ps1 -ExchangeServerNames MHServer1, MHServer2 -ExcludeVirtualDirectories "EWSFrontEnd"

Включение расширенной защиты с помощью диспетчера IIS

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

Примечание.

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

Установите для параметра Расширенная защита значение Обязательное или принять для в виртуальном каталоге

  1. Запустите на IIS Manager (INetMgr.exe) сервере Exchange Server, на котором требуется настроить расширенную защиту.
  2. Перейдите к Sites и выберите или Default Web SiteExchange Back End
  3. Выберите виртуальный каталог, который требуется настроить.
  4. Выберите Authentication
  5. Если Windows Authentication параметр включен, выберите Windows Authentication
  6. Выберите Advanced Settings (справа) и в открывающемся окне выберите подходящее значение в раскрывающемся списке Расширенная защита.

Задание параметра Обязательное ssl для виртуального каталога

  1. Щелкните виртуальный каталог, чтобы открыть домашнюю страницу.
  2. Выберите SSL Settings
  3. Require SSL Проверьте параметры, чтобы убедиться, что Require SSL для виртуального каталога включена
  4. Щелкните Apply , чтобы подтвердить новый параметр

Отключение расширенной защиты

Чтобы отключить расширенную защиту, можно использовать сценарий PowerShellExchangeExtendedProtectionManagement.ps1 .

Предупреждение

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

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

.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection

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

.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection -ExchangeServerNames ExchServer1, ExchServer2

Устранение неполадок

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

Известные проблемы с расширенной защитой

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

Проблема. При выполнении /PrepareSchema, /PrepareDomain или /PrepareAllDomains в автоматическом режиме Exchange Server 2019 CU14 программа установки показывает, что расширенная защита активирована.

Это известная проблема с Exchange Server 2019 CU14, которую можно игнорировать. Расширенная защита не включена при запуске /PrepareSchemaили /PrepareDomain/PrepareAllDomains для подготовки среды, как описано в документации по подготовке Active Directory и доменов для Exchange Server .

Проблема. Изменение разрешений для общедоступных папок с помощью клиента Outlook завершается сбоем со следующей ошибкой: "Измененные разрешения не могут быть изменены"

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

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

Предупреждения и ошибки при выполнении скрипта конфигурации расширенной защиты

  1. Скрипт отображает предупреждение об известных проблемах и запрашивает подтверждение:

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

  2. Скрипт не включает расширенную защиту из-за сбоя проверки готовности:

    • Ни на сервере Exchange Server не выполняется сборка, которая поддерживает расширенную защиту:

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

      Чтобы устранить эту проблему, обновите все серверы Exchange до последней версии CU и SU и запустите скрипт еще раз, чтобы включить расширенную защиту.

    • Обнаружено несоответствие TLS:

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

      Дополнительные сведения см. в рекомендациях по настройке TLS для Exchange Server .

  3. Некоторые серверы Exchange недоступны и недоступны:

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

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

Пользователи не могут получить доступ к своему почтовому ящику через один или несколько клиентов

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

  • Пользователи не могут получить постоянный или периодический доступ к почтовому ящику с помощью Outlook для Windows, Outlook для Mac, Outlook Mobile или собственного почтового клиента iOS:

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

    • Проверьте, используется ли разгрузка SSL . Любое завершение SSL приводит к сбою проверки маркера привязки канала расширенной защиты, так как разгрузка SSL считается человеком в середине, что предотвращается расширенной защитой. Чтобы устранить эту проблему, отключите разгрузку SSL и снова включите расширенную защиту с помощью скрипта.

  • Пользователи могут получать доступ к электронной почте с помощью Outlook для Windows и OWA, но не через клиенты, отличные от Windows, такие как Outlook для Mac, Outlook Mobile или собственный почтовый клиент iOS. Это может произойти, если параметру расширенной защиты для EWS и (или) Exchange ActiveSync задано значение Required на одном или всех Front-End серверах:

    • Чтобы устранить эту проблему, запустите ExchangeExtendedProtectionManagement.ps1 скрипт с параметром ExchangeServerNames и передайте имя сервера Exchange Server с неправильно настроенным параметром расширенной защиты. Вы также можете запустить скрипт без какого-либо параметра, чтобы снова проверить и настроить расширенную защиту для всех серверов.

    • Кроме того, можно также использовать IIS Manager (INetMgr.exe) и изменить параметр расширенной защиты для этих виртуальных каталогов на правильное значение, как указано в таблице. Мы настоятельно рекомендуем использовать скрипт, так как он проверяет правильные значения и выполняет перенастройку автоматически, если значения не заданы должным образом.

  • Пользователи не могут получить доступ к OWA или ECP с помощью браузера Apple Safari в macOS или iOS, если используется единый вход NTLM и включена расширенная защита:

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

Гибридная миграция "свободная/занят" или миграция почтовых ящиков не работает

Если вы используете современную гибридную среду, включение расширенной защиты может привести к тому, что гибридные функции, такие как доступность и миграция почтовых ящиков, перестают работать, если конфигурация не была выполнена, как описано в этой статье. Чтобы устранить эту проблему, определите гибридные серверы, опубликованные с помощью гибридного агента , и отключите расширенную защиту в виртуальном каталоге Front-End EWS на этих серверах.

Общедоступные папки больше не отображаются и недоступны

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

Вопросы и ответы

Вопрос: Требуется ли установить обновление для системы безопасности за август 2022 г., если оно уже было установлено в предыдущем накопительном пакете обновления (CU)?
Ответ: Да, при обновлении до более новой сборки CU необходимо снова установить su за август 2022 г. (например, Exchange Server 2019 CU11 до Exchange Server 2019 CU12).

Помните: Если вы планируете выполнить обновление немедленно (означает установку CU + SU), расширенную защиту не нужно выключать. Если вы планируете оставаться в CU без немедленной установки su, необходимо отключить расширенную защиту, так как сборка cu (без установки su) не поддерживает расширенную защиту и, следовательно, у вас могут возникнуть проблемы с подключением клиента.

Вопрос: Безопасно ли включить расширенную защиту в среде, которая использует службы федерации Active Directory (AD FS) для Outlook в Интернете (OWA)?
Ответ: Да, расширенная защита не влияет на проверку подлинности на основе утверждений AD FS с помощью OWA.

Вопрос: Безопасно ли включить расширенную защиту Windows в среде, которая использует гибридную современную проверку подлинности (HMA)?
Ответ: Да, это изменение не повлияет на HMA. Хотя расширенная защита еще больше не улучшает HMA, проверку подлинности Windows по-прежнему можно использовать для приложений, которые не поддерживают гибридную современную проверку подлинности. Учитывая это, включение расширенной защиты рекомендуется в любой среде, в которой по-прежнему есть локальные службы Exchange.

Вопрос: Влияет ли расширенная защита на гибридную современную проверку подлинности или интеграцию с Microsoft Teams?
Ответ: Расширенная защита не влияет на интеграцию Microsoft Teams или гибридную современную проверку подлинности.

Вопрос: Мне не удается получить доступ к OWA/ECP после включения расширенной защиты с кодом состояния HTTP 400, моя OWA/ECP публикуется через прокси приложения Entra, что можно сделать, чтобы устранить эту проблему?
Ответ: Публикация Exchange OWA/ECP через прокси приложения Entra не поддерживается. Вам потребуется опубликовать OWA/ECP через поддерживаемую топологию сети в соответствии с расширенными стандартами защиты.

Вопрос: Хотя мы понимаем, что предотвращение атак MitM важно, можем ли мы иметь собственные устройства в середине с собственными сертификатами?
Ответ: Если устройство использует тот же сертификат, что и сервер Exchange Server, их можно использовать.