Пошаговая инструкция по настройке публикации почтовых серверов Exchange Server 2013/2016 с помощью IIS ARR

imageПриветствую всех читателей нашего Блога! Сегодня я расскажу вам о том, как за несколько минут настроить публикацию почтового сервера Exchange Server 2013/2016 с помощью IIS ARR (Application Request Routing). Но для начала немного о том, что такое публикация и для чего она нужна.

Основная задача публикации это защита сервера от внешнего негативного воздействия. Сервер публикации Reverse Proxy (RP), располагается в сети периметра (DMZ) и передает (проксирует) запросы на почтовые сервера, в том случае, если запросы соответствуют определенным шаблонам. Логика работы RP на основе компонента ARR следующая: если поступает запрос с именем узла mail.contoso.com по протоколу HTTPS, тогда перенаправить запрос на ферму серверов mail.contoso.com. Все просто и понятно. Веб сервер используется по той простой причине, что в Exchange 2013/2016 ВСЕ подключения (кроме POP и IMAP конечно!) идут через HTTPS и неважно что вы используете, браузер или толстый клиент Outlook.

image

 

Некоторые особенности RP серверов на основе IIS ARR:

  1. Сервер RP может не быть членом домена.
  2. Сервер должен иметь доступ к внутренней сети организации (конкретно к почтовым серверам) и внешней сети Интернет. Один из вариантов реализации это два сетевых адаптера.
  3. RP должен разрешать FQDN (полное доменное имя ex1-srv.contoso.com, ex2-srv.contoso.com и т.д.) почтового сервера в его IP адрес. Если в сети периметра не используется DNS сервер, необходимо прописать имена серверов и IP в файле C:\Windows\System32\Drivers\etc\hosts.
  4. Убедитесь, что вы правильно настроили внутренние и внешние URL для виртуальных каталогов на почтовом сервере и правильно сконфигурировали сервера. Прежде чем приступать к публикации, проверьте, что все отлично функционирует в пределах локальной сети.
  5. DNS-суффикс сервера RP (в том случае, если он не включен в домен) нужно настроить вручную так, чтобы он был идентичен доменному (RP.contoso.com).
  6. Убедитесь, что виртуальные каталоги (OWA, ECP, EWS и т.д.) опубликованы для внешних подключений с пространством имен mail.contoso.com

Приступим к установке.

1) Запустить PowerShell с привилегиями Администратора и выполнить

Import-Module ServerManager
Add-WindowsFeature Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Net-Ext,Web-Http-Logging,Web-Request-Monitor,Web-Http-Tracing,Web-Filtering,Web-Stat-Compression,Web-Mgmt-Console,NET-Framework-Core,NET-Win-CFAC,NET-Non-HTTP-Activ,NET-HTTP-Activation,RSAT-Web-Server

Проверим что все получилось, введя в браузере сервера RP http://127.0.0.1

2) Устанавливаем Microsoft Web Platform Installer. В поиске Microsoft Web Platform Installer набираем ARR и устанавливаем пакет Application Request Routing 3.0 + дополнительные компоненты предложенные установщиком.

3) Экспортируем сертификат с CAS сервера и импортируем на сервер RP. Необходимо привязать этот сертификат для Default Web Site

Bind

 

4) Переходим в Server Farms и создаем новую ферму серверов. Назовем ее Contoso.com

 

image

 

Добавим сервера в ферму (Если роли разнесены, то добавляем только CAS сервера). Вводим FQDN сервера и нажимаем ADD

 

image

Нажимаем Finish, затем YES на предложение создать правила.

5) Необходимо настроить ферму, в которую мы добавили наши почтовые сервера. Открываем ферму contoso.com и переходим в раздел Caching. Убираем чекбокс Enable Disk Cache и нажимаем Apply

 

image

 

Переходим в раздел Health Test. В качестве URL для проверки доступности серверов я укажу:

  • https://autodiscover.contoso.com/Autodiscover/HealthCheck.htm

URL для проверки доступности имеет вид https://<fqdn>/<protocol>/HealthCheck.htm это URL по умолчания для Exchange Server 2013/2016. Для каждого протокола существует свой URL и его нет необходимости настраивать дополнительно, это все часть компонента Managed Availability. Можно указать другие URL для соответствующих протоколов:

  • https://mail.contoso.com/EWS/HealthCheck.htm
  • https://mail.contoso.com/OAB/HealthCheck.htm
  • https://mail.contoso.com/OWA/HealthCheck.htm

Настройки для раздела Health Test (после внесения изменений, не забываем нажимать Apply)

 

image

 

После внесения всех настроек нужно проверить, что все работает. Нажмем Verify URL Test и убедимся, что все серверы прошли проверку, ответив Pass. Если сервер не будет доступен, то на него не будут пересылаться запросы от внешних клиентов. Компонент ARR выведет его из балансировки до тех пор, пока снова не “увидит” сервер клиентского доступа.

Переходим к разделу Proxy, выставляем настройки:

  • Time-Out: 200 seconds
  • Response Buffer threshold: 0

не забываем нажимать Apply после внесения изменений.

image

 

Переходим в раздел Routing Rules и убираем чекбокс Enable SSL Offloading

 

image

Load Balance, Monitoring and Management и Server Affinity не трогаем.

6) Переходим к созданию правил перенаправления запросов.

В оснастке IIS открываем URL Rewrite

image

 

Создаем правило для Autodiscover

image

 

Для добавления шаблона во вкладке “Conditions” нажать “Add” и ввести параметры:

 

image

Аналогично ввести “{HTTPS} ON”

В самом низу выбираем действие, которое необходимо выполнить, если запрос соответствует шаблону. В нашем случае, это перенаправление на ферму серверов (не забывайте выбрать https) и чекбокс запрещающий выполнение следующих (нижних) правил.

image

Готово.

Аналогичным образом создаем правило для mail.contoso.com и, ели есть желание, для activesync.contoso.com.

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

Последний штрих. Перейдите в “Request Filtering” 

image

Далее

image

 

и задайте значение 2147483648 для параметра “Maximum allowed content lenght”.

Всё готово! Теперь необходимо настроить внешние DNS сервера, для разрешения имен Autodiscover и mail (а если настраивали, то и activesync) в IP IIS ARR.

Очень полезная ссылка:

Reverse Proxy for Exchange Server 2013 using IIS ARR

По просьбам трудящихся закрываем ECP

4

Всего комментариев: 36 Комментировать

  1. Sergey Korotkov /

    Спасибо за статью!
    Все хорошо в ARR но CBA не поддерживается (

    1. guznin /

      Настроить можно, но тогда лучше включить IISARR в домен. CBA в основном для MDM используется. А для MDM Exchange не подходит, от слова вообще :-)

      1. Sergey Korotkov /

        А можно в двух словах, чуть подробнее, куда копать, или где почитать?
        ARR-ы в домене.
        Мне как раз для мобильников больше.
        Когда последний раз подступался к этой задаче - не осилил. Так и создали в итоге отдельную вирт.директорию EAS-а с CBA мимо ARR.

        1. guznin /

          Можно тут почитать:
          https://blogs.msdn.microsoft.com/asiatech/2014/01/27/configuring-arr-with-client-certificate/

          https://www.iis.net/configreference/system.webserver/security/authentication/iisclientcertificatemappingauthentication

          Но это заморочка страшная. Лучше MDM внедрить, airwatch какой-нибудь или что-то типа того.

          з.ы.
          Сам я такого зверя не настраивал, но коллеги практиковали.

  2. Алексей Максимов /

    Получается, что такой сервер с IIS ARR может стать точкой отказа для внешних пользователей при том, что внутри организации может быть организована избыточность. Возможно повышение доступности? Если да, то каким образом (в трёх словах, чтобы понять суть)?

    1. guznin /

      Можно развернуть их два и балансить либо DNS RoundRobin либо NLB.

  3. Алексей Максимов /

    И ещё вопрос. Какие выгоды от использования IIS ARR в отличие от Web Application Proxy? Вроде как для публикации после отказа от TMG все вокруг пропагандировали именно WAP.

    1. guznin /

      Это делалось т.к. WAP прокси заточено под О365. Из явных плюсов это отсутствие ADFS (а это минус один сервер). Если кратко, то IISARR это простой и действенный способ публикации web сервисов.

  4. Vladimir /

    Добрый день. А как реализовано ограничение доступа к ECP? Я так понимаю открыв из вне адрес https://mail.contoso.com/ECP/ , я смогу попасть к форме логина в ecp

    1. guznin /

      Простой пользователь переходя по https://mail.contoso.com/ECP/ попадает в настройки своего ящика, где может настраивать автоответы, язык, часовой пояс и т.д. Если его заблокировать, то он не сможет это делать. Если это устраивает ОK. Сегодня вечером добавлю правило, запрещающее переход к ECP.

      1. Vladimir /

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

        1. Константин Гузнин / Автор записи

          Это ИБ, это совсем другая тема. Можно отключить EAC и оставить только ECP. При этом для EAC сделать отдельный сервер который не публиковать. Я так делал, опыт был :-) Статью обновил.

  5. Вадим Иванычев /

    благодарю за статью
    не давно тоже задались вопросом перевода публикаций с isa2006 :)
    выбор пал на cisco asa 5510
    чем данный вариант лучше\хуже, можете в 2х словах рассказать (кроме "Health Test" ,url фильтрации и как софтовое решение разницы для себя пока не вижу)

    1. Константин Гузнин / Автор записи

      Если прочитаете информацию по ссылке (а там три статьи) то увидите достаточно широкий диапазон функционала. В принципе, все что нужно для публикации Exchange, в IIS ARR есть. Плюсы ASA в том, что она может не только публиковать)) Минусы в том, что нужно знать циску (т.е. иметь доп спеца, если это крупная контора то и двух), плюс, для отказоустойчивости их должно быть две. Если только для публикации, то ARR вполне хватит.

  6. x-user /

    Хорошая статья. Собрали на тестовом стенде, два сервера, Exchange 2013sp1 + Edge, IIS ARR. Всё работает внутри. Снаружи, работает owa и activesync, а вот autodiscover нет. При запросе https://autodiscover.x-x.ru/autodiscover/autodiscover.xml выдаёт ошибку 404. Сертификат есть, dns имя прописано, если 143 порт пробросить на прямую на Exchange, autodiscover отрабатывает как нужно. Не подскажите в чём может быть проблема?

    1. guznin /

      Если делали все по статье, то должно отрабатывать без проблем.

      1) проверьте правило
      2) проверьте, что ARR может попасть на https://autodiscover.x-x.ru/autodiscover/autodiscover.xml (в том числе, что он резолвит autodiscover.x-x.ru)
      3) Сделайте тест autodiscover на сайте https://testconnectivity.microsoft.com/

      1. x-user /

        1. Действительно была опечатка в условии {HTTPS} - on
        Теперь вводим https://autodiscover.x-x.ru/autodiscover/autodiscover.xml выдаёт запрос на логин/пароль, после ввода которых появляется 502 ошибка.
        2. ARR резолвит адрес через внешний dns. ARR стоит в DMZ внутренний адрес exchange сервера прописан в hosts. По внутренним адресам arr получает autodiscover.xml
        3. Все проверки проходят кроме этой:
        Attempting to send an Autodiscover POST request to potential Autodiscover URLs
        Autodiscover settings weren't obtained when the Autodiscover POST request was sent.
        Additional Details
        Elapsed Time: 2568 ms.
        Test Steps
        The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://autodiscover.x-x.ru:443/Autodiscover/Autodiscover.xml for user testuser@x-x.ru.
        The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.
        Additional Details
        A Web exception occurred because an HTTP 502 - BadGateway response was received from IIS7.
        HTTP Response Headers:
        Content-Length: 1447
        Content-Type: text/html
        Date: Sun, 09 Oct 2016 13:27:14 GMT
        Server: Microsoft-IIS/8.5
        X-Powered-By: ASP.NET
        Elapsed Time: 2567 ms.

        1. x-user /

          Проблема решилась установкой патча от Microsoft "Hotfix for Microsoft Application Request Routing Version 2.5 for IIS7 (KB 2732764) (x64)" https://www.microsoft.com/en-us/download/details.aspx?id=30333
          Можно кстати добавить это в статью, чтобы сэкономить людям время в будущем.
          Благодарю за быстрый ответ и за статью!

          1. guznin /

            Поэтому я написал, что нужно ставить версию 3.0))

  7. Стас /

    Константин, приветствую. Для чего необходимо указывать DNS-суффикс сервера RP, если RP не в домене ? Без этого не будет работать ? Стоит задача опубликовать два RD Gateway на одном IP, публичных IP мало. При этом RD Gateway относятся к двум разным доменам AD, никак не связанным друг с другом. Такая схема вообще может работать ? Правила публикации схожи с Exchange, поэтому задаю вопрос здесь.

    1. guznin /

      Добрый день! Могут быть проблемы с сертификатом, особенно с сертификатом вида *.domain.ru
      В остальном, это вполне рабочая схема, должна работать на 2 домена, без проблем.

      1. Стас /

        Костя, а какие именно ? Я выгружу сертификаты в *.pfx с закрытыми ключами с обоих RD GW и импортирую на RP. DNS работает как надо. У меня не получилось заставить работать: с самого RP на обоих RD GW странички RD Web открываются корректно, когда иду снаружи на RP по URL любого из RD GW получаю ошибку, что невозможно отобразить содержимое каталога IIS, мол, не те учетные данные. Хотя броузер их и не запрашивает. Да и не должен по идее, ведь учетные данные обычно уже в форме на странице RDWeb нужно вводить. В какую сторону смотреть ?

  8. Alex /

    Это все не нужно и дополнительное усложнение архитектуры. Периметр защищает asa либо делается простой проброс порта 443 на cas и все. Сама microsoft и многие mvp говорят что этой схемы достаточно. Если есть балансировщик то проброс портов на него делается.

    1. guznin /

      1) Проброс порта и публикация это совершенно разные вещи
      2) Если умрет outlook anywhere, а все остальные сервисы будут работать, то asa и т.п. так и будут кидать клиентов на этот сервер и вы получите вал заявок, в то время как ARR может проверять здоровье сервиса и не подключать к нему клиентов. Этот как пример, более подробно описано по ссылки в статье.

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

  9. Denis Goncharenko /

    День добрый.
    Все сделал как в статье не работает 502 ошибка и хоть ты тресни.

    Суть в следующем IIS находится в домете 1.com а exchange в домене 2.com видят друг друга замечатьльно
    когда прихожу с локальной машины находящейся в домене 1.com и ввожу Url https://iisnames.1.com/owa получаю

    502 - Web server received an invalid response while acting as a gateway or proxy server.
    There is a problem with the page you are looking for, and it cannot be displayed. When the Web server (while acting as a gateway or proxy) contacted the upstream content server, it received an invalid response from the content server.

    1. guznin /

      Внимательно проверьте настройки IIS ARR. Убедитесь, что healthcheck нормально работает.

  10. Руслан /

    RDGW (TSGW) опубликовать через IIS ARR реально? что то ни одной статьи на эту тему не попалось

    1. Константин Гузнин / Автор записи
  11. Михаил /

    Добрый день! Всё сделано как в статье и вообщем то всё работает, кроме почтового клиента spark от readdle. Он использует службу EWS, но при попытке подключения ругается на невозможность подключения к серверу, и в логах говорит: https://mail.***.ru/EWS/Exchange.asmx not found. Хотя если этот адрес вводить в браузере, то он запрпшивает логин пароль и отображает страницу. Если публикация не используется, то подключается без проблем по тому же 443 порту. Подскажите пожалуйста в чём может быть проблема?

    1. guznin /

      Добрый день! EWS это важная штука, ее используют некоторые мобильные приложения и аутлук для маков (и ещё куча продуктов, S4B например). Если серверов более чем один, то есть вариант сценария, при котором через прокси и напрямую вы заходите на разные сервера. Внимательно посмотрите правила, все ли https запросы идут на ферму серверов. Так же советую ознакомиться с расширенным функционалом реверс прокси (https://blogs.technet.microsoft.com/exchange/2013/08/02/part-2-reverse-proxy-for-exchange-server-2013-using-iis-arr/) Смысл в том, что для каждого сервиса почты (owa, ecp, ews...) создается своя ферма с урлом для проверки доступности. И если на сервере упала owa, клиенты туда перенаправляться не будут. Ну и Get-ServerComponetState я бы тоже запустил, на почтаре.

      1. Михаил /

        Спасибо! Всё заработало. Заново создал правило. Видимо где то ошибся в первый раз.

        1. guznin /

          Это стандартная ситуация, нельзя просто так взять и настроить IIS ARR с первого раза)

  12. Максим /

    Здравствуйте! Возможно ли с помощью данной статьи настроить публикацию ActiveSync и OWA для Exchange Server 2010?

    1. Константин Гузнин /

      *Lazy mode off* Да, для 2010 все будет работать. Так же, если пройдете по ссылочкам, там будут статьи, как настроить фермы для разных сервисов. Например: создаете ферму для активсинка, настраиваете проверку сервера по uri активистка и публикуете сервера. И так для всех служб. Если на одном из 4 серверов, к примеру, не работает ова, клиенты по ова туда не пойдут, но у него работает активсинк и по активистку клиенты будут коннектиться.

  13. Евгений /

    Добрый день!
    Вопрос со стороны ИБ. Коллеги, подскажите, а какой уровень логгирования у такого решения? Насколько подробно с помощью IIS ARR можно проследить работу пользователя, например, с сервисом OWA? Когда подключался, какие письма открывал, какие вложения скачивал..?

    1. Mr. Toad /

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

Добавить комментарий