Приветствую всех читателей нашего Блога! Сегодня я расскажу вам о том, как за несколько минут настроить публикацию почтового сервера 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.
Некоторые особенности RP серверов на основе IIS ARR:
- Сервер RP может не быть членом домена.
- Сервер должен иметь доступ к внутренней сети организации (конкретно к почтовым серверам) и внешней сети Интернет. Один из вариантов реализации это два сетевых адаптера.
- RP должен разрешать FQDN (полное доменное имя ex1-srv.contoso.com, ex2-srv.contoso.com и т.д.) почтового сервера в его IP адрес. Если в сети периметра не используется DNS сервер, необходимо прописать имена серверов и IP в файле C:\Windows\System32\Drivers\etc\hosts.
- Убедитесь, что вы правильно настроили внутренние и внешние URL для виртуальных каталогов на почтовом сервере и правильно сконфигурировали сервера. Прежде чем приступать к публикации, проверьте, что все отлично функционирует в пределах локальной сети.
- DNS-суффикс сервера RP (в том случае, если он не включен в домен) нужно настроить вручную так, чтобы он был идентичен доменному (RP.contoso.com).
- Убедитесь, что виртуальные каталоги (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
4) Переходим в Server Farms и создаем новую ферму серверов. Назовем ее Contoso.com
Добавим сервера в ферму (Если роли разнесены, то добавляем только CAS сервера). Вводим FQDN сервера и нажимаем ADD
Нажимаем Finish, затем YES на предложение создать правила.
5) Необходимо настроить ферму, в которую мы добавили наши почтовые сервера. Открываем ферму contoso.com и переходим в раздел Caching. Убираем чекбокс Enable Disk Cache и нажимаем Apply
Переходим в раздел 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)
После внесения всех настроек нужно проверить, что все работает. Нажмем Verify URL Test и убедимся, что все серверы прошли проверку, ответив Pass. Если сервер не будет доступен, то на него не будут пересылаться запросы от внешних клиентов. Компонент ARR выведет его из балансировки до тех пор, пока снова не “увидит” сервер клиентского доступа.
Переходим к разделу Proxy, выставляем настройки:
- Time-Out: 200 seconds
- Response Buffer threshold: 0
не забываем нажимать Apply после внесения изменений.
Переходим в раздел Routing Rules и убираем чекбокс Enable SSL Offloading
Load Balance, Monitoring and Management и Server Affinity не трогаем.
6) Переходим к созданию правил перенаправления запросов.
В оснастке IIS открываем URL Rewrite
Создаем правило для Autodiscover
Для добавления шаблона во вкладке “Conditions” нажать “Add” и ввести параметры:
Аналогично ввести “{HTTPS} ON”
В самом низу выбираем действие, которое необходимо выполнить, если запрос соответствует шаблону. В нашем случае, это перенаправление на ферму серверов (не забывайте выбрать https) и чекбокс запрещающий выполнение следующих (нижних) правил.
Готово.
Аналогичным образом создаем правило для mail.contoso.com и, ели есть желание, для activesync.contoso.com.
В получившемся списке, первым должно идти правило Autodiscover, затем activesync, после mail. Правила отрабатывают по очереди, одно за другим. Перемещать правила в списке можно с помощью стрелок вверх и вниз, находящихся слева.
Последний штрих. Перейдите в “Request Filtering”
Далее
и задайте значение 2147483648 для параметра “Maximum allowed content lenght”.
Всё готово! Теперь необходимо настроить внешние DNS сервера, для разрешения имен Autodiscover и mail (а если настраивали, то и activesync) в IP IIS ARR.
Очень полезная ссылка:
Reverse Proxy for Exchange Server 2013 using IIS ARR
По просьбам трудящихся закрываем ECP
RSS - Записи
Спасибо за статью!
Все хорошо в ARR но CBA не поддерживается (
Настроить можно, но тогда лучше включить IISARR в домен. CBA в основном для MDM используется. А для MDM Exchange не подходит, от слова вообще :-)
А можно в двух словах, чуть подробнее, куда копать, или где почитать?
ARR-ы в домене.
Мне как раз для мобильников больше.
Когда последний раз подступался к этой задаче - не осилил. Так и создали в итоге отдельную вирт.директорию EAS-а с CBA мимо ARR.
Можно тут почитать:
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 какой-нибудь или что-то типа того.
з.ы.
Сам я такого зверя не настраивал, но коллеги практиковали.
Получается, что такой сервер с IIS ARR может стать точкой отказа для внешних пользователей при том, что внутри организации может быть организована избыточность. Возможно повышение доступности? Если да, то каким образом (в трёх словах, чтобы понять суть)?
Можно развернуть их два и балансить либо DNS RoundRobin либо NLB.
И ещё вопрос. Какие выгоды от использования IIS ARR в отличие от Web Application Proxy? Вроде как для публикации после отказа от TMG все вокруг пропагандировали именно WAP.
Это делалось т.к. WAP прокси заточено под О365. Из явных плюсов это отсутствие ADFS (а это минус один сервер). Если кратко, то IISARR это простой и действенный способ публикации web сервисов.
Добрый день. А как реализовано ограничение доступа к ECP? Я так понимаю открыв из вне адрес https://mail.contoso.com/ECP/ , я смогу попасть к форме логина в ecp
Простой пользователь переходя по https://mail.contoso.com/ECP/ попадает в настройки своего ящика, где может настраивать автоответы, язык, часовой пояс и т.д. Если его заблокировать, то он не сможет это делать. Если это устраивает ОK. Сегодня вечером добавлю правило, запрещающее переход к ECP.
Я имел ввиду злоумышленника (из вне), который получить доступ к форме логина ECP и сможет попытаться взломать (перебором или другим способом) аккаунт с повышенными привилегиями на Exchange. Думаю дополнить статью способом защиты от такого сценария будет не лишним.
Это ИБ, это совсем другая тема. Можно отключить EAC и оставить только ECP. При этом для EAC сделать отдельный сервер который не публиковать. Я так делал, опыт был :-) Статью обновил.
благодарю за статью
не давно тоже задались вопросом перевода публикаций с isa2006 :)
выбор пал на cisco asa 5510
чем данный вариант лучше\хуже, можете в 2х словах рассказать (кроме "Health Test" ,url фильтрации и как софтовое решение разницы для себя пока не вижу)
Если прочитаете информацию по ссылке (а там три статьи) то увидите достаточно широкий диапазон функционала. В принципе, все что нужно для публикации Exchange, в IIS ARR есть. Плюсы ASA в том, что она может не только публиковать)) Минусы в том, что нужно знать циску (т.е. иметь доп спеца, если это крупная контора то и двух), плюс, для отказоустойчивости их должно быть две. Если только для публикации, то ARR вполне хватит.
Хорошая статья. Собрали на тестовом стенде, два сервера, Exchange 2013sp1 + Edge, IIS ARR. Всё работает внутри. Снаружи, работает owa и activesync, а вот autodiscover нет. При запросе https://autodiscover.x-x.ru/autodiscover/autodiscover.xml выдаёт ошибку 404. Сертификат есть, dns имя прописано, если 143 порт пробросить на прямую на Exchange, autodiscover отрабатывает как нужно. Не подскажите в чём может быть проблема?
Если делали все по статье, то должно отрабатывать без проблем.
1) проверьте правило
2) проверьте, что ARR может попасть на https://autodiscover.x-x.ru/autodiscover/autodiscover.xml (в том числе, что он резолвит autodiscover.x-x.ru)
3) Сделайте тест autodiscover на сайте https://testconnectivity.microsoft.com/
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.
Проблема решилась установкой патча от 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
Можно кстати добавить это в статью, чтобы сэкономить людям время в будущем.
Благодарю за быстрый ответ и за статью!
Поэтому я написал, что нужно ставить версию 3.0))
Константин, приветствую. Для чего необходимо указывать DNS-суффикс сервера RP, если RP не в домене ? Без этого не будет работать ? Стоит задача опубликовать два RD Gateway на одном IP, публичных IP мало. При этом RD Gateway относятся к двум разным доменам AD, никак не связанным друг с другом. Такая схема вообще может работать ? Правила публикации схожи с Exchange, поэтому задаю вопрос здесь.
Добрый день! Могут быть проблемы с сертификатом, особенно с сертификатом вида *.domain.ru
В остальном, это вполне рабочая схема, должна работать на 2 домена, без проблем.
Костя, а какие именно ? Я выгружу сертификаты в *.pfx с закрытыми ключами с обоих RD GW и импортирую на RP. DNS работает как надо. У меня не получилось заставить работать: с самого RP на обоих RD GW странички RD Web открываются корректно, когда иду снаружи на RP по URL любого из RD GW получаю ошибку, что невозможно отобразить содержимое каталога IIS, мол, не те учетные данные. Хотя броузер их и не запрашивает. Да и не должен по идее, ведь учетные данные обычно уже в форме на странице RDWeb нужно вводить. В какую сторону смотреть ?
Это все не нужно и дополнительное усложнение архитектуры. Периметр защищает asa либо делается простой проброс порта 443 на cas и все. Сама microsoft и многие mvp говорят что этой схемы достаточно. Если есть балансировщик то проброс портов на него делается.
1) Проброс порта и публикация это совершенно разные вещи
2) Если умрет outlook anywhere, а все остальные сервисы будут работать, то asa и т.п. так и будут кидать клиентов на этот сервер и вы получите вал заявок, в то время как ARR может проверять здоровье сервиса и не подключать к нему клиентов. Этот как пример, более подробно описано по ссылки в статье.
з.ы. ну и при прямом пробросе портов могут убить сервер DDoS атакой, а в случае ARR умрет только ARR.
День добрый.
Все сделал как в статье не работает 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.
Внимательно проверьте настройки IIS ARR. Убедитесь, что healthcheck нормально работает.
RDGW (TSGW) опубликовать через IIS ARR реально? что то ни одной статьи на эту тему не попалось
Лучше через WAP https://technet.microsoft.com/en-US/library/dn765486(WS.11).aspx
Добрый день! Всё сделано как в статье и вообщем то всё работает, кроме почтового клиента spark от readdle. Он использует службу EWS, но при попытке подключения ругается на невозможность подключения к серверу, и в логах говорит: https://mail.***.ru/EWS/Exchange.asmx not found. Хотя если этот адрес вводить в браузере, то он запрпшивает логин пароль и отображает страницу. Если публикация не используется, то подключается без проблем по тому же 443 порту. Подскажите пожалуйста в чём может быть проблема?
Добрый день! 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 я бы тоже запустил, на почтаре.
Спасибо! Всё заработало. Заново создал правило. Видимо где то ошибся в первый раз.
Это стандартная ситуация, нельзя просто так взять и настроить IIS ARR с первого раза)
Здравствуйте! Возможно ли с помощью данной статьи настроить публикацию ActiveSync и OWA для Exchange Server 2010?
*Lazy mode off* Да, для 2010 все будет работать. Так же, если пройдете по ссылочкам, там будут статьи, как настроить фермы для разных сервисов. Например: создаете ферму для активсинка, настраиваете проверку сервера по uri активистка и публикуете сервера. И так для всех служб. Если на одном из 4 серверов, к примеру, не работает ова, клиенты по ова туда не пойдут, но у него работает активсинк и по активистку клиенты будут коннектиться.
Добрый день!
Вопрос со стороны ИБ. Коллеги, подскажите, а какой уровень логгирования у такого решения? Насколько подробно с помощью IIS ARR можно проследить работу пользователя, например, с сервисом OWA? Когда подключался, какие письма открывал, какие вложения скачивал..?
Вряд ли это возможно.
В логах можно будет найти только время и внешний адрес.
Это же обратный прокси, который просто разруливает запросы по доменным именам, аналог NGINX, как сказать, с некоторыми плюшками для продуктов microsoft.