Таблица поддержки exchange server

Создание группы высокой доступности

Последним подготовительным шагом для наших серверов Exchange 2019 станет процесс создания группы высокой доступности (Database Availability Group – DAG).

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

  1. Создание группы высокой доступности в конфигурации.
  2. Добавление почтовых серверов в группу высокой доступности.
  3. Настройка дополнительных копий почтовых баз.

Важный момент – поскольку у нас всего два почтовых сервера, то кворум они собрать не смогут и им нужен сервер свидетель. Поскольку размещать свидетеля на контроллере домена далеко не самая хорошая практика (даже в тестовой среде), то мы подготовим отдельный сервер – SRV01.

Более подробно про кворумы можно почитать в документации на сайте Microsoft.

Подготовка сервера свидетеля

В качестве сервера свидетеля мы будем использовать сервер SRV01. Операционная система – Windows Server 2012 R2. Этот сервер мы использовали в качестве сервера свидетеля при настройке DAG для Exchange 2016, т.е. все необходимые шаги по его подготовке мы уже выполнили. Если один и тот же сервер выступает в качестве свидетеля для нескольких DAG, то для каждой группы высокой доступности создается своя отдельная директория:

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

1. Установить и выполнить первоначальную настройку операционной системы.

2. Выполнить настройку IP-адресации.

3. Установить все обновления для ОС.

4. Присоединить сервера к домену itproblog.ru.

5. Добавить группу Active Directory “Exchange Trusted Subsystem” в группу локальных администраторов.

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

Первый шаг создания DAG на сервере Exchange 2019 – создание объекта группы высокой доступности в конфигурации Exchange. Создадим группу высокой доступности:

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

В таком случае вам необходимо либо отключить брандмауэр на сервере свидетеле, либо включить следующие правила брандмауэра:

Добавление почтовых серверов в группу высокой доступности

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

Добавим первый сервер:

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

Теперь добавим в группу высокой доступности второй почтовый сервер:

Посмотрим теперь на нашу группу высокой доступности:

Мы видим, что оба наших сервера представлены в колонке “Member Server”, т.е. оба сервера были успешно добавлены в группу высокой доступности.

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

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

Основная суть в том, чтобы, например, для почтовой базы DB05, которая расположена на сервере MBX05, создать дополнительную копию на сервере MBX06. В случае выхода из строя сервера MBX05, почтовая база DB05 будет автоматически активирована на сервере MBX06. Аналогичное справедливо и для почтовой базы DB06 на сервере MBX06.

Создадим дополнительную копию почтовой базы DB05 на сервере MBX06. Выполним следующий командлет на сервер MBX05:

Теперь создадим дополнительную копию почтовой базы DB06 на сервере MBX05. Выполним следующий командлет на сервер MBX06:

Первоначальная настройка Exchange 2016 Database Availability Group завершена, но еще давайте посмотрим в конфигурацию дополнительных копий баз данных:

Мы видим, что для почтовой базы DB05 создано две копии:

  1. На сервере MBX05. Это основная копию и её статус “Mounted”, т.е. она смонтирована на сервере MBX05, т.к. в соответствующей колонке “Status” для сервера MBX05 указано значение “Mounted”.
  2. На сервере MBX06. Это дополнительная копия, т.к. в соответствующей колонке “Status” для сервера MBX06 указано значение “Healthy”. В случае непредвиденной аварии сервер MBX06 готов подхватить базу.

Нулевые значения в колонках “Copy Queue Length” и “Replay Queue Length” говорят о том, что почтовая база успешно реплицируется между серверами MBX05 и MBX06.

Настройка группы высокой доступности завершена.

Поддерживаемые среды Active Directory

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

Среда операционной системы Exchange 2019 Exchange 2016 cu12 и более поздней Exchange 2016 cu7 и более поздний Exchange 2016 cu3 to CU6 Exchange 2016 с накопительным пакетом обновления 2 (CU2) и более ранних версий Exchange 2013 с пакетом обновления 1 (SP1) и более поздних версий Exchange 2010 SP3 RU22 или более поздней Exchange 2010 SP3 RU5 — RU21
Windows Серверы Active Directory Server 2019 Поддерживается Поддерживается Не поддерживается Не поддерживается Не поддерживается Не поддерживается Не поддерживается Не поддерживается
Серверы Active Directory с Windows Server 2016 Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Не поддерживается
Серверы Windows Server 2012 R2 Active Directory Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается
Серверы Active Directory на базе Windows Server 2012 Не поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается
Серверы Active Directory на основе Windows Server 2008 R2 с пакетом обновления 1 (SP1) Не поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается
Серверы Active Directory на базе Windows Server 2008 с пакетом обновления 2 (SP2) Не поддерживается Не поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается
Серверы Active Directory на базе Windows Server 2003 с пакетом обновления 2 (SP2) Не поддерживается Не поддерживается Не поддерживается Не поддерживается Поддерживается Поддерживается Поддерживается Поддерживается
Функциональный уровень леса AD Exchange 2019 Exchange 2016 cu7 и более поздний Exchange 2016 cu3 to CU6 Exchange 2016 с накопительным пакетом обновления 2 (CU2) и более ранних версий Exchange 2013 с пакетом обновления 1 (SP1) и более поздних версий Exchange 2010 SP3 RU22 или более поздней Exchange 2010 SP3 RU5 — RU21
Windows Server 2016 Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Не поддерживается
Windows Server 2012 R2 Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается
Windows Server 2012 Не поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается
Windows Server 2008 R2 Не поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается
Windows Server 2008 Не поддерживается Не поддерживается Поддерживается Поддерживается Поддерживается Поддерживается Поддерживается
Windows Server 2003 Не поддерживается Не поддерживается Не поддерживается Поддерживается Поддерживается Поддерживается Поддерживается

Что делать, если мне нужна помощь?

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

Если во время миграции в Microsoft 365 возникают проблемы и вы не используете FastTrack или переходите в более новую версию Exchange Server, можно использовать некоторые ресурсы:

  • Техническое сообщество
  • Служба поддержки клиентов

Архитектура и основные векторы атак на MS Exchange

Основные компоненты сервера MS Exchange и связи между ними представлены на схеме ниже.

В зависимости от версии у MS Exchange могут быть следующие роли:

  • Сервер почтовых ящиков (Mailbox server).
  • Сервер клиентского доступа (Client Access) — фронтенд-сервис, который проксирует клиентские запросы на бэкенд-серверы.
  • Транспорт (Transport), который отвечает за управление почтовым потоком.
  • Единая система обмена сообщениями (Unified Messaging), которая позволяет использовать голосовые сообщения и другие возможности телефонии (роль недоступна на серверах версии 2019).
  • Управление (Management role), суть которого состоит в администрировании и гибкой настройке компонентов MS Exchange.

Табл. 1. Основные протоколы, используемые MS Exchange

Типы протоколов Название Описание
Протоколы клиентского доступа HTTP/HTTPS Протокол, который используется клиентами, в том числе мобильными, чтобы обращаться к компонентам Exchange для работы с почтой, календарями, адресной книгой и т. д.
MAPI Транспортный протокол для работы с почтой и другими компонентами, который используется клиентом Outlook для взаимодействия с сервером Exchange. Он имеет ряд преимуществ за счет инкапсуляции в HTTP
RPC over HTTP Альтернативный транспортный протокол, который используется клиентом Outlook и мобильными устройствами
Протоколы для пересылки и хранения почты SMTP Протокол передачи почты в сетях TCP/IP
IMAP4/POP3 Протоколы прикладного уровня для доступа к электронной почте
Протокол обмена данными со службой каталогов Active Directory LDAP Открытый протокол, который используется для хранения и извлечения данных из иерархической структуры каталогов

Основные компоненты Exchange и их краткое описание приведены ниже:

  • Outlook Web Access (OWA) — веб-интерфейс для предоставления доступа к почтовым ящикам и работы с ними (чтение/отправка/удаление почты, редактирование календаря и т. д.)
  • Exchange Control Panel (ECP) — веб-интерфейс для администрирования компонентов Exchange: управления почтовыми ящиками, создания различных политик для управления почтовым потоком, подключения новых почтовых серверов и т. д.
  • Autodiscover — служба, позволяющая клиентам получать информацию о расположении различных компонентов сервера Exchange, например URL для службы EWS. Для получения информации требуется предварительная аутентификация пользователя.
  • Exchange Web Services (EWS) — API для предоставления различным приложениям доступа к компонентам почтовых ящиков.
  • Exchange ActiveSync (EAS) — сервис, позволяющий пользователям мобильных устройств получать доступ к электронной почте, календарю, контактам, задачам и работать с этой информацией без подключения к интернету.
  • RPC — служба клиентского доступа через протокол RPC, который работает поверх HTTP.
  • Offline Address Book (OAB) — служба автономной адресной книги сервера Exchange, которая позволяет пользователям Outlook кешировать содержимое GAL (Global Address List) и обращаться к нему даже при отсутствии подключения к Exchange.

Все вышеописанные компоненты функционируют как приложения на веб-сервере Microsoft IIS.

Атакуя сервер MS Exchange, злоумышленники, как правило, преследуют следующие цели:

  • Получение доступа к конфиденциальной информации, содержащейся в корпоративной почте.
  • Запуск вредоносной рассылки с адресов компании-жертвы для проникновения в инфраструктуру другой организации.
  • Компрометация УЗ с помощью компонентов Exchange (успешная брутфорс-атака или обнаружение учетных данных в почтовой переписке) для входа в сеть компании через один из корпоративных сервисов.
  • Закрепление в сети компании (например, с помощью веб-шелла на сервисе OWA).
  • Повышение привилегий в домене с помощью сервера Exchange.
  • Выведение из строя сервера Exchange для нарушения внутренних бизнес-процессов компании (например, полное шифрование данных сервера).

Настройка клиентов Outlook на использование Outlook Anywhere

Прежде чем подключиться по Outlook Anywhere, необходимо выполнить ряд настроек на клиенте. В Outlook 2010 перейдите в настройки учетной записи Account Settings.

Дважды щелкните по настроенному профилю Exchange.

Нажмите кнопку More Settings, и перейдите на вкладку Connection.

Отметьте опцию Connect to Microsoft Exchange using HTTP, и затем нажмите кнопку Exchange Proxy Settings.

Введите внешнее DNS имя сервера (мы его указывали ранее при настройке сервера CAS), затем в разделе Proxy Authentication Settings выберите заданный ранее тип аутентификации.

Нажмите дважды OK, затем Next и Finish. Для вступления новых параметров подключения в силу необходимо перезапустить Outlook.

Теперь Outlook 2010 настроен на Outlook Anywhere, и можно безопасно подключаться к своему ящику Exchange через интернет.

Обнаружение эксплуатации CVE-2020-16875

Успешная эксплуатация уязвимости CVE-2020-16875 позволяет злоумышленнику выполнять произвольный код на сервере Exchange в контексте пользователя System. В дальнейшем атакующий может повысить свои привилегии в домене и скомпрометировать всю сеть организации.

Для успешной аутентификации требуется доменная учетная запись от корпоративного почтового ящика, которая состоит в группе с правами Data Loss Prevention (дальше будем называть ее DLP). Эксплуатация производится через компонент DLP. Настройка DLP осуществляется через интерфейс ECP. Механизм DLP позволяет фильтровать почтовый поток по заданным паттернам и правилам на основе анализа содержимого писем и их вложений.

Поскольку мы уже знаем, что для успешной эксплуатации атакующий должен состоять в DLP-группе, то на эту активность можно реализовать правило на создание новой группы с ролью , а также добавление в группу нового пользователя. Такие действия можно осуществить как с помощью интерфейса ECP, так и с помощью Exchange Management Shell, используя следующие команды:

  • (создание группы dlp users с ролью и добавление в нее пользователя user1);

  • (добавление пользователя dadmin в группу dlp users).

Ниже приведен скриншот события добавления пользователя dadmin в группу с помощью интерфейса ECP. Также эту активность можно проследить по событиям аудита PowerShell (Event ID 800 и 4104).

Добавление пользователя dadmin в группу dlp users (журнал MSExchange Management)

Выдачу прав с помощью событий аудита PowerShell и журнала MSExchange Management можно отследить при помощи следующего правила:

Эксплоит для этой уязвимости последовательно выполняет следующие шаги:

  1. Аутентификация под заданной учетной записью для получения сессии через OWA.
  2. Получение параметра ViewState с помощью обращения к функциональности управления политикой DLP.
  3. Добавление новой вредоносной DLP-политики, которая содержит исполняемую команду, запускаемую с помощью PowerShell.

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

Успешная эксплуатация уязвимости CVE-2020-16875

В access-логах ECP содержится событие успешного добавления новой DLP-политики:

Правило на создание новой DLP-политики с использованием событий IIS:

При эксплуатации уязвимости создается новая политика, поэтому в журнале MSExchange Management мы увидим событие добавления этой политики со случайным именем, содержащее вредоносную полезную нагрузку в параметре :

Событие создания новой DLP-политики (журнал MSExchange Management)

Обнаружить создание новой DLP-политики по событиям журналов PowerShell и MSExchange Management можно при помощи следующего правила:

Результат эксплуатации уязвимости — запуск Notepad. В событиях старта процессов, содержащихся в журнале Security, можно увидеть запуск процесса родительским процессом с привилегиями System.

Событие старта процесса (журнал Security)

Обнаружить успешную эксплуатацию уязвимости CVE-2020-16875 можно при помощи уже рассмотренного выше правила:

Другой вариант эксплоита на PowerShell имеет схожую логику и выполняет следующие действия:

  1. Создает удаленную PowerShell-сессию с помощью компонента PowerShell сервера Exchange. Подключение осуществляется под учетной записью, имеющей роль `Data Loss Prevention`.Фрагмент кода создания удаленной PowerShell-сессии
  2. Создает новую политику с помощью командлета `New-DlpPolicy`. Полезная нагрузка хранится в переменной $xml:Запуск New-DlpPolicy в рамках удаленной PowerShell-сессии

Ниже показан результат запуска PowerShell-эксплоита с успешным подключением под непривилегированным пользователем user1 и выполнением команды whoami с привилегиями System.

В событиях IIS видно создание удаленной сессии:

Правило, детектирующее эту активность:

В журнале Security можно обнаружить факт успешного старта процесса whoami с родительским процессом . Выполнение команды по журналу аудита PowerShell обнаруживается одним из ранее упомянутых правил.

Событие запуска whoami

Как происходит прямая миграция?

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

  1. Администратор сообщает пользователям о предстоящих изменениях и проверяет право собственности на домен с помощью регистратора доменных имен.

  2. Администратор подготавливает серверы к переносу переключе и создает пустые группы безопасности с поддержкой почты в Microsoft 365 или Office 365.

  3. Администратор подключает Microsoft 365 или Office 365 к локальной системе электронной почты (это называется созданием конечной точки миграции).

  4. Администратор переносит почтовые ящики и проверяет успешность миграции.

  5. Предоставление Microsoft 365 или Office 365 лицензий пользователям.

  6. Администратор настраивает домен, чтобы приступить к маршрутике электронной почты непосредственно Microsoft 365 или Office 365.

  7. Администратор проверяет, происходит ли перенаправление, а затем удаляет пакет прямой миграции.

  8. Администратор завершает задачи после миграции в Microsoft 365 или Office 365 (назначает лицензии пользователям и создает запись системы имен доменных имен автооткрытого домена (DNS) и необязательно выводит из эксплуатации Exchange серверов.

  9. Администратор отправляет пользователям приветственное письмо, в котором рассказывает о Microsoft 365 или Office 365 и описывает, как войти в новые почтовые ящики. (См. обзор Outlook профиля электронной почты для получения сведений о создании новых Outlook профилей).

Как убедиться, что это сработало?

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

  1. Создайте новый профиль в приложении Outlook и/или на устройстве ActiveSync. Убедитесь, что новый профиль успешно создается в Outlook или на мобильном устройстве.

  2. В Outlook или на мобильном устройстве отправьте новое сообщение внешнему получателю. Убедитесь, что внешний получатель получил сообщение.

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

  4. Перейдите по адресу https://owa.contoso.com/owa, чтобы убедиться в отсутствии предупреждений о сертификате.

Переименование и перемещение баз данных

Перед настройкой Database Availability Group нам нужно будет выполнить некоторые подготовительные работы:

  1. Дать более понятное имя почтовым базам.
  2. Переместить файлы почтовых баз на отдельный выделенный диск.

Сейчас у нас по одной на каждом сервере Exchange 2016. Посмотреть их мы можем следующим командлетом:

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

Сначала переименуем наши почтовые базы в конфигурации:

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

Мы совместим процесс переименование физических файлов почтовой базы и процесс переноса физических файлов почтовой базы на отдельный выделенный диск. В нашем случае необходимо выполнить следующий командлет на первом сервере Exchange 2016 (MBX03):

Нас предупредят о том, что на время переноса почтовая база будет недоступна:

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

Выполним аналогичный командлет на втором сервере Exchange 2016 (MBX04):

Переименование и перемещение почтовых баз завершено.

Высокая степень интеграции в инфраструктуру

Exchange Server 2016 — это высокоинтегрированная платформа для коммуникаций. И если ИТ-инфраструктура вашей компании построена на программном обеспечении Microsoft, то вы получите максимальные преимущества, максимальную безопасность и наибольшую лёгкость в управлении. Exchange полностью опирается на службу каталогов (домен) Active Directory, вам не придётся по 2 раза заводить пользователей в домене и на почтовом сервере отдельно. Системным администраторам не придётся настраивать рабочие станции пользователей, Outlook 2013 и Outlook 2016 сами подключатся к серверу Exchange и настроятся автоматически при помощи служб автообнаружения. Exchange Server 2016 интегрируется с Forefront Threat Management Gateway 2013 (ранее называвшийся ISA Server), обеспечивая наивысший уровень защищённости от внешних угроз. Exchange интегрируется с такими продуктами, как Microsoft CRM и SharePoint, а объединение Microsoft Exchange Server и Microsoft Office Communications Server представляет собой мощное решение для объединенных коммуникаций (Unified Communications).

Что же такое Outlook Anywhere?

Outlook Anywhere – это служба, реализованная на серверах CAS (Client Access server), позволяющая клиентам Outlook удаленно подключаться к почтовым ящикам по безопасным протоколам SSL/HTTPS. В версиях Exchange, предшествующих Exchange 2007 и 2010, подобная функция носила название RPC-over-HTTPS.

Смысл технологии Outlook Anywhere заключается в упаковке стандартных RPC запросов Outlook в HTTPS, трафик которого может проходить через корпоративное шлюзы и файерволы по стандартным портам SSL/HTTPS без необходимости открытия RPC диапазона портов.

Для активации функционала Outlook Anywhere в среде Exchange 2010 необходимо:

Рекомендации по сертификатам Exchange

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

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

    Например, если все общие имена будут находиться на одном уровне contoso.com, не имеет значения, какой сертификат использовать (SAN или групповой). Но для autodiscover.contoso.com, autodiscover.fabrikam.com и autodiscover.northamerica.contoso.com необходимо использовать сертификат SAN.

  • Используйте сертификаты из коммерческого ЦС для клиентских и внешних подключений к серверу. Хотя большинство клиентов могут доверять любому эмитенту сертификата или сертификата, гораздо проще использовать сертификат из коммерческого ЦС для клиентских подключений к Exchange серверам. Клиенту не требуется конфигурация, чтобы доверять сертификату, выданным коммерческим ЦС. Многие коммерческие CAs предлагают сертификаты, настроенные специально для Exchange. Вы можете использовать EAC или Exchange для создания запросов сертификатов, которые работают с большинством коммерческих ЦС.

  • Выберите правильный коммерческий центр сертификации: сравните цены и функции сертификатов между ЦС. Например:

    • Убедитесь, что центру сертификации доверяют клиенты (операционные системы, браузеры и мобильные устройства), которые подключаются к серверам Exchange.

    • Убедитесь, что ЦС поддерживает необходимый вам сертификат. Например, не все ЦС поддерживают сертификаты SAN, ЦС может ограничивать количество допустимых общих имен в сертификате SAN или взимать дополнительную плату исходя из количества общих имен в сертификате SAN.

    • Узнайте, предоставляет ли ЦС льготный период, в течение которого в сертификаты SAN можно бесплатно добавлять дополнительные общие имена.

    • Убедитесь, что лицензия позволяет использовать сертификат на нужном количестве серверов. Некоторые ЦС позволяют использовать сертификат только на одном сервере.

  • Используйте мастер Exchange сертификата. Распространенная ошибка при создании сертификатов — забыть одно или несколько распространенных имен, необходимых для служб, которые вы хотите использовать. Мастер сертификатов в центре администрирования Exchange поможет включить правильный список общих имен в запрос сертификата. Мастер позволяет указать службы, которые будут использовать сертификат, и включает общие имена, необходимые для этих служб. Запустите мастер сертификатов при развертывании исходного набора серверов Exchange 2016 или Exchange 2019 г. и определите, какие имена хостов будут использовать для различных служб для развертывания.

  • Используйте как можно меньше имен хостов. Минимизация числа имен хостов в сертификатах SAN снижает сложность управления сертификатами. Не чувствуйте себя обязанными включать имена отдельных серверов Exchange в сертификаты SAN, если это не требуется для использования для сертификата. Как правило, необходимо включать имена DNS, которые представлены внутренним клиентам, внешним клиентам или внешним серверам, которые используют сертификат для подключения к Exchange.

    Для простой Exchange Server организации с именем Contoso это гипотетический пример минимальных имен хостов, которые потребуются:

    • mail.contoso.com. Это имя хост охватывает большинство подключений к Exchange, включая Outlook, Outlook в Интернете, рассылку OAB, Exchange веб-службы, Exchange центр администрирования и Exchange ActiveSync.

    • autodiscover.contoso.com. Это конкретное имя хост-сайта требуется клиентам, которые поддерживают автонаруже, включая Outlook, Exchange ActiveSync и Exchange веб-службы. Дополнительные сведения см. в службе автооткрытия.

Benefits of using Outlook Anywhere

Outlook Anywhere offers the following benefits to clients that use Outlook 2013, Outlook 2010, or Outlook 2007 to access your Exchange messaging infrastructure:

  • Users have remote access to Exchange servers from the Internet.

  • You can use the same URL and namespace that you use for Outlook Web App and Microsoft Exchange ActiveSync.

  • You can use the same Secure Sockets Layer (SSL) server certificate that you use for both Outlook Web App and Exchange ActiveSync.

  • Unauthenticated requests from Outlook can’t access Exchange servers.

  • You don’t have to use a virtual private network (VPN) to access Exchange servers across the Internet.

  • If you already use Outlook Web App with SSL or Exchange ActiveSync with SSL, you don’t have to open any additional ports from the Internet.

  • You can test end-to-end client connectivity for Outlook Anywhere and TCP-based connections by using the Test-OutlookConnectivity cmdlet.

Шаг 6. Настройка SSL-сертификата

Некоторые службы, такие как мобильный Outlook и Exchange ActiveSync, требуют настройки сертификатов на сервере Exchange Server. Ниже показано, как настроить SSL-сертификат от стороннего центра сертификации (ЦС).

    • Сертификат следует запросить у стороннего ЦС, чтобы клиенты автоматически ему доверяли. Дополнительные сведения см. в статье .

    • Если внутренний и внешний URL-адреса совпадают, в полях Outlook в Интернете (при доступе через Интернет) и Outlook в Интернете (при доступе через интрасеть) будет показан адрес owa.contoso.com. В полях Автономная адресная книга (при доступе через Интернет) и Автономная адресная книга (при доступе через интрасеть) будет показан адрес mail.contoso.com.

    • Если заданы внутренние URL-адреса формата internal.contoso.com, в поле Outlook в Интернете (при доступе через Интернет) будет показан адрес owa.contoso.com, а в поле Outlook в Интернете (при доступе через интрасеть) — адрес internal.contoso.com.

    • Как минимум, следует выбрать SMTP и IIS.

    • При появлении предупреждения Перезаписать существующий SMTP-сертификат по умолчанию? нажмите кнопку Да.

Как убедиться, что все получилось?

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

  1. В Центре администрирования Exchange последовательно выберите пункты Серверы > Сертификаты.

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

    • значение параметра Состояние равно Действительный;

    • в поле Назначен службам указаны как минимум IIS и SMTP.

Шаг 6. Настройка SSL-сертификата

Некоторые службы, такие как мобильный Outlook и Exchange ActiveSync, требуют настройки сертификатов на сервере Exchange Server. Ниже показано, как настроить SSL-сертификат от стороннего центра сертификации (ЦС).

    • Сертификат следует запросить у стороннего ЦС, чтобы клиенты автоматически ему доверяли. Дополнительные сведения см. в статье .

    • Если внутренний и внешний URL-адреса совпадают, в полях Outlook в Интернете (при доступе через Интернет) и Outlook в Интернете (при доступе через интрасеть) будет показан адрес owa.contoso.com. В полях Автономная адресная книга (при доступе через Интернет) и Автономная адресная книга (при доступе через интрасеть) будет показан адрес mail.contoso.com.

    • Если заданы внутренние URL-адреса формата internal.contoso.com, в поле Outlook в Интернете (при доступе через Интернет) будет показан адрес owa.contoso.com, а в поле Outlook в Интернете (при доступе через интрасеть) — адрес internal.contoso.com.

    • Как минимум, следует выбрать SMTP и IIS.

    • При появлении предупреждения Перезаписать существующий SMTP-сертификат по умолчанию? нажмите кнопку Да.

Как убедиться, что все получилось?

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

  1. В Центре администрирования Exchange последовательно выберите пункты Серверы > Сертификаты.

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

    • значение параметра Состояние равно Действительный;

    • в поле Назначен службам указаны как минимум IIS и SMTP.

Шаг 1. Создание соединителя отправки в Интернет

Чтобы отправлять почту в Интернет, необходимо создать соединитель отправки на сервере почтовых ящиков. Инструкции см. в статье Создание соединителя отправки в Exchange Server для отправки почты в Интернет.

Примечание

По умолчанию при установке Exchange создается соединитель получения под названием «Интерфейсный сервер <ServerName>_ по умолчанию». Этот соединитель принимает анонимные подключения SMTP с внешних серверов. Вам не требуется проводить какую-либо дополнительную настройку, если это вас устраивает. Если вы хотите ограничить входящие подключения с внешних серверов, измените соединитель получения Интерфейсный сервер <Mailbox server> по умолчанию на сервере почтовых ящиков. Дополнительные сведения см. в разделе .

Шаг 5. Маршрут электронной почты непосредственно в Microsoft 365 или Office 365

Почтовые системы используют запись DNS, которая называется записью MX, чтобы определять, куда нужно доставить электронную почту. В процессе миграции электронной почты запись MX указывала на вашу исходную систему электронной почты. Теперь, когда миграция электронной почты Microsoft 365 или Office 365 завершена, пришло время указать запись MX в Microsoft 365 или Office 365. Это помогает убедиться, что электронная почта доставляется в Microsoft 365 или Office 365 почтовые ящики. Перемещение записи MX также позволит отключить старую почтовую систему, когда вы будете готовы.

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

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

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Ваша ОС
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: