Продолжаем знакомиться с новыми возможностями ОС Windows Server 2012 R2. Ранее мы рассказывали о корпоративном аналоге DropBox в Windows Server 2012 R2 под названием Work Folders. Сегодня речь пойдет о еще одном новшестве новой серверной платформы – функции Web Application Proxy. Web Application Proxy – это новая функция роли Remote Access в Windows 2012 R2, позволяющая публиковать HTTP/ HTTPS приложения, расположенные в периметре корпоративной сети на клиентских устройствах (в первую очередь подразумеваются мобильные устройства) за ее периметром. Благодаря возможности интеграции c AD FS (служба может выступать в качестве ADFS-прокси), возможно обеспечить аутентификацию внешних пользователей, пытающихся получить доступ к опубликованным приложениям.
Web Application Proxy предоставляет такие же возможности публикации приложений, как и Forefront Unified Access Gateway (UAG), однако данная служба также позволяет взаимодействовать с другими серверами и сервисами, обеспечивая тем самым более гибкую и рациональную конфигурацию.
Web Application Proxy по сути выполняет функцию обратного прокси сервера (HTTP reverse proxy), организуя ретрансляцию запросов клиентов из внешней сети на внутренний сервер, и является межсетевым экраном на прикладном уровне.
Сервер со службой Web Application Proxy получает внешний HTTP/HTTPS трафик и терминирует его, после чего от своего имени инициирует новое подключение ко внутреннему приложению (веб-серверу). Т.е. внешние пользователи прямого доступа к внутреннему приложению реально не получают. Любой другой трафик, получаемый Web Application Proxy, отклоняется (в том числе отклоняются HTTP/HTTPS запросы, которые могут быть использованы при DoS, SSL и 0-day атаках).
Требования к организации Web Application Proxy и ключевые особенности:
- Систему можно развернуть на серверах с ОС Windows Server 2012 R2, включенных в домен Active Directory, с ролями AD FS и Web Application Proxy. Эти роли должны быть установлены на разных серверах.
- Необходимо обновить схему Active Directory до Windows Server 2012 R2 (обновлять контроллеры домена до Windows Server 2012 R2 не нужно)
- В качестве клиентских устройств поддерживаются устройства с ОС Windows, IOS (iPad и iPhone). Работы над клиентами для Android и Windows Phone пока еще не окончены
- Аутентификация клиентов осуществляется службой Active Directory Federation Services (ADFS), которая также выполняет функции ADFS – проксирования.
- Типовая схема размещения сервера с ролью Web Application Proxy представлена на рисунке. Данный сервер располагается в выделенной DMZ зоне и отделен от внешней (Интернет) и внутренней сети (Интранет) межсетевыми экранами. В этой конфигурации для работы Web Application Proxy требует наличия двух интерфейсов – внутреннего (Intranet) и внешнего (DMZ)
Установка роли ADFS в Windows Server 2012 R2
Для обеспечения дополнительной безопасности преаутентифкация внешних клиентов выполняется на сервере ADFS, в противном случае используется pass-through аутентификация на конечном сервере приложения (что менее секьюрно). Поэтому первый шаг при настройке Web Application Proxy – установка на отдельном сервере роли Active Directory Federation Services.
При установке ADFS нужно выбрать SSL сертификат, который будет использоваться для шифрования, а также DNS имена, которые будут использоваться клиентами при подключении (соответствующие записи в DNS зоне придется создать самостоятельно).
Затем нужно указать сервисную учетную запись для службы ADFS. Необходимо учесть, что имя ADFS должно быть указано в атрибут Service Principal Name аккаунта. Сделать это можно командой:
setspn –F –S host/adfs.winitpro.ru adfssvc
И, наконец, указать базу данных, в которой будет хранится информация: это может быть встроенная база на этом же сервере (WID — Windows Internal Database) или отдельная база на выделенном SQL-сервере.
Установка службы Web Application Proxy
Следующий этап, настройка самой службы Web Application Proxy. Напомним, что служба Web Application Proxy в Windows Server 2012 R2 является частью роли “Remote Access”. Установите службу Web Application Proxy и запустите мастер ее настройки.
На первом этапе мастер предложит Вам указать имя ADFS сервера и параметры учетной записи, имеющей доступ к данной службе.
Далее нужно указать сертификат (убедитесь, что в альтернативных именах сертификата содержится имя сервера ADFS).
Публикация приложения через Web Application Proxy
После того, как установлены роли ADFS и Web Application Proxy (которая работает еще и как ADFS Proxy), можно перейти непосредственно к публикации наружу конкретного приложения. Сделать это можно с помощью консоли Remote Access Management Console.
Запустите мастер публикации и укажите, хотите ли вы использовать для преаутентификации службу ADFS (это именно наш вариант).
Затем нужно задать имя публикуемого приложения, используемый сертификат, внешний URL (имеенно его для подключения будут использовать внешние пользователи) и внутрений URL-адрес сервера, на который будут пересылаться запросы.
Backend server URL: lync.winitpro.local:4443
Завершите работу мастера, и на этом публикация приложений окончена. Теперь, если попытаться с помощью браузера зайти на опубликованный внешний URL-адрес, то браузер сначала будет перенаправлен на службу аутентификации (ADFS Proxy), а после успешной аутентификации пользователь будет отправлен непосредственно на внутренний сайт (веб приложение).
Благодаря новой службе Web Application Proxy в Windows Server 2012 R2 возможно реализовать функционал обратного прокси сервера с целью публикации внутренних служб предприятия наружу без необходимости использования задействовать сторонние файерволы и продукты, в том числе такие, как Forefront и пр.
А если несколько внешних адресов Web App Proxy их всё слушать будет?
Что значит будет слушать? Несколько IP можно задействовать с целью обеспечения высокой доступности сервера (ip от разных провайдеров), но обычно внешние клиенты привязываются не к ip адресам, а к dns имени.
Не совсем ясно, Ваша статья начинается со схемы публикации где указан web proxy между двумя фаерволами, а заканчиватся «…без необходимости использования задействовать сторонние файерволы и продукты, в том числе такие, как Forefront ..»
Какие же тогда фаерволы использовать согласно схеме и нужны ли они?
Файрволы между адфс и прокси — это разделение на внутренню и DMZ. еще один элемент общей безопасности.
так если ваш wap в домене, то какой это dmz?
Добрый день,
подскажите пожалуйста!
у нас есть сервер ADFS в домене, Exchange в домене и WAP в ДМЗ зоне который вне домена.
Мы используем сертификат выпущенный IIS Exchange.
Может лучше использовать SSL сертификат с ADFS?
У нас вроде как связь есть, мы вроде как опубликовали OWA, мы заходим по внешней URL, нас перекидывает на сервер и просит аутентификацию, мы вводим учетные записи и пароли, после этого выдает ошибку HTTP 500 либо просто белый экран.
Подскажите где мы могли ошибиться?
Готового ответа дать не смогу… Нужно журналы копать на предмет выявления ошибок.
Попробуйте для начала настроить и отладить WAP для доступа снаружи к тестовому https сайту (его можно развернуть прямо на сервере с Exchange) с Windows аутентификацией.
Доброго времени суток уважаемые коллеги. Есть домен, в домене пытаюсь инсталировать службу ADFS на WS 2012 R2.
Что делаю: ввел сервер в домен, создал УЗ «adfs-svc» от которой будет работать служба ADFS, запросил SSL сертификат для сервера, начинаю устанавливать ADFS, после указания сертификата при установке необходимо прописать SPN для службы от которой будет запускаться ADFS ,а именно setspn -F -S HOST/adfs.main.local adfs-svc — но команда прерывает выполнение с уведомлением, что есть дубликаты SPN.Но этого не могло быть, так как никто не мог назначить SPN , так как имя вообще новое.Соответственно последняя часть установки ADFS ругается-дескать надо прописать вручную SPN.Эта штука критичная, ошибка могут возникать при windows-аутентификации. Было замечено, что при вводе в домен сервера как рядового, автоматом назначаются SPN имена+ те которые я не прописывал -в допонительных атрибутах видно.Только в ручную их и удалить можно.
Вопрос: почему так происходит, может есть где гллубже почитать про это ? В другом домене такого замечено не было..
Спасибо!
«… Web Application Proxy требует наличия двух интерфейсов – внутреннего (Intranet) и внешнего (DMZ) …»
Подскажите, пожалуйста, как WAP правильно включается в сеть — на схеме оба интерфейса вроде бы включены в DMZ? У них адреса из одной подсети? Или внутренний интерфейс (Intranet) включается в локальную сеть? Тогда это подключение в обход второго файрвола…
как обновить сертификат на WAP ??