Внимание! Материал, изложенный в этой статье не актуален. Ниже обновлённая версия:
Публикация Exchange Server с помощью ADFS / Web Application Proxy
Операционная система Windows Server 2012 R2 предоставила в руки системных администраторов интересные изменения и дополнения к существовавшим ранее возможностям. Этим сообщением в своем блоге я открываю цикл из 5 статьей, которые ознакомят читателей с некоторыми из нововведений. Сегодняшняя речь пойдет о Web Application Proxy.
Web Application Proxy (далее просто WAP) используется как средство публикации внутрикорпоративных приложений, таких как Exchange, Lync и др. для внешних клиентов. Технология основывается на «реверс-проксировании» краткие сведения о котором будут изложены далее.
Для иллюстрации описываемого будет использован демо-стенд, на котором произойдет публикация Exchange 2013 с последующей настройкой его служб для аутентификации средствами, собственно, самого WAP. Данный инструмент позволяет гибко настраивать критерии доступа к конкретному приложению, например, по наличию нужных групп.
В результате тестирования на лабораторном стенде была успешно проделана публикация приложений OWA, ECP, PowerShell, OAB, RPC, EWS, Autodiscover, ActiveSync Отображение всего процесса будет показано в последующих статьях.
Содержание
- Немного теории
- Обзор Web Application Proxy
- Требования к развертыванию Web Application Proxy
- Описание лабораторного стенда
Немного теории
Web Application Proxy (WAP) – это reverse proxy server (сервер обратного проксирования). Если кратко, суть сводится к следующему:
Приложение публикуется на этом специально выделенном сервере-посреднике и внешний клиент сначала устанавливает соединение с посредником, а тот, в свою очередь, инициализирует подключение к публикуемому приложению от своего имени.
Такой подход позволяет решить проблемы:
- Предварительная аутентификация клиентов для подключения к приложению;
- Фильтрация подключений и проверка трафика;
- Публикации нескольких приложений под одним доменным именем;
- Гибких сценариев балансировки нагрузки и отказоустойчивости.
Обзор Web Application Proxy
На прикладном уровне, Web Application Proxy (WAP) является дополнительной службой роли Remote Access в Server 2012 R2. Для реализации WAP за основу была взята служба роли ADFS Federation Service Proxy в Windows Server 2012, решавшая задачу Front-end сервера при развертывании служб федерации Active Directory.
WAP расширил возможности публикации. Теперь помимо публикации самих служб ADFS стало возможным публиковать другие HTTPS приложения такие как Exchange, Lync и др.
В Windows Server 2012 R2 существует два типа предварительной аутентификации клиентов посредством WAP:
- Active Directory Federation Services (ADFS) – В этом случае используются либо ADFS Claim, либо встроенная проверка подлинности Windows по протоколу Kerberos.
- Pass-through, сквозная аутентификация. В данном варианте WAP не будет самостоятельно производить аутентификация клиентов, а пропускать через себя запросы далее, в том виде в каком они есть.
В практических демонстрация будут использоваться оба типа, так как пока не все публикуемые приложения Exchange поддерживают ADFS аутентификацию.
Требования к развертыванию Web Application Proxy
- Для развертывания WAP необходимо иметь минимум 2 сервера с ОС Windows Server 2012 R2, включенные в домен Active Directory. На первом сервере должна быть установлена роль ADFS, на втором – служба роли Remote Access, Web Application Proxy.
- Схема леса Active Directory должна быть расширена до уровня Sevrer 2012 R2. В тоже время, можно использовать домен-контроллеры, работающие под управлением предыдущей версий операционной системы Windows Server 2012.
Описание лабораторного стенда
Исследование WAP будет выполнено на лабораторном стенде, работающем под управлением Windows Server 2012 R2 Datacenter с установленной ролью Hyper-V. На сервере создано 3 виртуальных коммутатора: WAN, LAN и DMZ.
Ниже представлена упрощенная топология стенда – WAP Network
В качестве маршрутизатора использовался Endian Firewall community, основанный на Linux. Маршрутизатор реализует «трехногую» конфигурацию, образовывая 2 частных сети DMZ и LAN.
Адресное пространство DMZ — 192.168.1.0/24, а для LAN — 172.16.20.0/24.
Весь процесс конфигурирования разбит на логические части, каждая представляет отдельную статью, ниже список:
Спасибо за очень интересный материал. Данный вопрос как раз очень актуален. ◾Схема леса Active Directory должна быть расширена до уровня Sevrer 2012 R2. В тоже время, можно использовать домен-контроллеры, работающие под управлением предыдущих версий операционных систем, например, Windows Server 2012. Пара вопросов по данному утверждению: – где указано это требование? Я нашел только вот такое “All of the Active Directory domains in a multi-forest deployment must have at least one Windows Server® 2012 or higher domain controller.” Вот здесь: http://technet.microsoft.com/en-us/library/dn383648.aspx – мне казалось, что схема работы леса не может быть выше, чем схема работы самого старого домена и то же… Подробнее »
Дмитрий, спасибо за хороший вопрос.
Это требование не самого WAP а служб федерации ADFS 2012 R2. Так как WAP c ADFS не могут работать раздельно, можно считать что это так же будет требованием WAP.
Раздел, в котором находится схема един для всех контроллеров домена в пределах леса. И как только мы осуществляем расширение схемы, изменения сразу же инициализируются мастером схемы по всем контроллерам домена во всем лесу в виде репликации раздела схемы.
Версия схемы никаким образом не зависит от режима работы леса или домена. А само расширение схемы представляет из себя только добавление новых класов и атрибутов.
Да. Был неправ. Попутал уровень схемы и уровень функционирования. Однако, наверное, правильнее написать “хотя бы один конроллер домена 2012 или выше”, как у Микрософт. А то ведь можно поставить контроллер 2012. Это поднимет уровень схемы. Потом его снести. Уровень схемы, насколько я знаю не опуститься (нет команды forestprep наоборот) а AD FS работать не будет (понятно, что такая ситуация несколько синтетическая).
Дмитрий,
Согласен, немного поменяю формулировку в статье.