Web Application Proxy в Server 2012 R2, функционал и использование на примере публикации приложений Exchange 2013 (часть 1)

Операционная система 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:

  1. Active Directory Federation Services (ADFS) – В этом случае используются либо ADFS Claim, либо встроенная проверка подлинности Windows по протоколу Kerberos.
  2. 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

Лабораторный стенд Web application proxy

В качестве маршрутизатора использовался Endian Firewall community, основанный на Linux. Маршрутизатор реализует «трехногую» конфигурацию, образовывая 2 частных сети DMZ и LAN.

Адресное пространство DMZ — 192.168.1.0/24, а для LAN — 172.16.20.0/24.

Весь процесс конфигурирования разбит на логические части, каждая представляет отдельную статью, ниже список:

  1. Развертывание и конфигурирование служб федерации Active Directory
  2. Развертывание и конфигурирование Web Application Proxy
  3. Подготовка служб Exchange Server 2013 к публикации
  4. Публикация служб Exchange Server 2013, тестирование и выводы

4 thoughts on “Web Application Proxy в Server 2012 R2, функционал и использование на примере публикации приложений Exchange 2013 (часть 1)

  1. Спасибо за очень интересный материал.
    Данный вопрос как раз очень актуален.
    ◾Схема леса 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
    – мне казалось, что схема работы леса не может быть выше, чем схема работы самого старого домена и то же самое касается контроллеров и домена. То есть в лесу 2008R2 можно использовать домен 2012 и в нём контроллер 2012R2 но не наоборот.

    • Дмитрий, спасибо за хороший вопрос.
      Это требование не самого WAP а служб федерации ADFS 2012 R2. Так как WAP c ADFS не могут работать раздельно, можно считать что это так же будет требованием WAP.
      Раздел, в котором находится схема един для всех контроллеров домена в пределах леса. И как только мы осуществляем расширение схемы, изменения сразу же инициализируются мастером схемы по всем контроллерам домена во всем лесу в виде репликации раздела схемы.
      Версия схемы никаким образом не зависит от режима работы леса или домена. А само расширение схемы представляет из себя только добавление новых класов и атрибутов.

      • Да. Был неправ. Попутал уровень схемы и уровень функционирования. Однако, наверное, правильнее написать “хотя бы один конроллер домена 2012 или выше”, как у Микрософт. А то ведь можно поставить контроллер 2012. Это поднимет уровень схемы. Потом его снести. Уровень схемы, насколько я знаю не опуститься (нет команды forestprep наоборот) а AD FS работать не будет (понятно, что такая ситуация несколько синтетическая).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.