Знакомимся с Web Application Proxy на Windows Server 2012 R2

Прекратив поддержку Threat Management Gateway (ранее ISA server) MS поставила в ступор многих админов, которым требовалось решения для публикации приложений с проверкой подлинности. Forefront Unified Access Gateway вроде и обеспечивал нужное, но не предлагал практически никаких функций безопасности (в декабре 2013 было объявлено, что следующих версий уже не будет). Некоторое время положение было непонятно, пока в Win2012R2 не была представлена новая роль Web Application Proxy.

Назначение Web Application Proxy

Web Application Proxy (WAP, прокси сервер веб-приложений) представляет собой обратный (reverse) прокси позволяющий администратору публиковать приложения для доступа из вне. Работает WAP просто. Сервер получает на внешний адрес HTTPS запрос от клиента (в текущей версии только HTTPS) и ретранслирует его на внутреннее приложение по HTTP или HTTPS. За основу WAP взята служба роли AD FS Federation Service Proxy решавшая задачу Front-end сервера при развертывании служб федерации Active Directory (в Win2012R2 AD FS анонсирован уже версии 3.0). По сути WAP выполняет функции прокси AD FS, обеспечивая аутентификацию пользователей и контроль доступа на основе заявок (Claims Based Access, CBA) средствами AD FS.
Запрос на подключение, WAP со всеми параметрами перенаправляет вначале на AD FS. После чего пользователь должен будет пройти процесс аутентификации (посредством Active Directory через Kerberos или NTLM авторизации) и авторизации. Поддерживается все продвинутые функции: многофакторная аутентификация (Multifactor authentication, MFA) и контроль доступа (Мultifactor Access control), когда могут быть использованы дополнительные ступени – одноразовый пароль или смарт-карта. После проверки подлинности сервер AD FS выдает SSO маркер безопасности, содержащий идентификатор пользователя и ресурса к которому пользователь хочет получить доступ, срок предоставления доступа. WAP получив ответ AD FS инициирует отдельное соединение к конечному серверу, сохранив всю информацию о доступе в Cookies. Внутренний сервер проверяет маркер и клиент получает доступ без ввода пароля.
Как видим клиент на прямую не контактирует с приложением, WAP выступает как буфер уровня сеанса обеспечивая дополнительную защиту. Любой другой трафик (включая известные сетевые и SSL атаки) приходящий на веб-прокси отбрасывается и не передается опубликованному приложению. Приложения могут использовать один IP-адрес/порт, дифференциация производится по имени.
Многие обратные прокси производят только аутентификацию учетной записи и пользователь может подключаться к приложению с любого устройства. Это является потенциальной проблемой безопасности. WAP взаимодействуя со службой Device Registration Service (DRS) производит проверку маркера аутентификации (сертификата) устройства пользователя, гарантируя, что только разрешенные девайсы смогут получить доступ к корпоративным ресурсам. Также обеспечивается работа Workplace Join дающая возможность пользователям получать доступ к корпоративным ресурсам с мобильных устройств.
На github, можно найти расширения к AD FS позволяющие более гибко управлять устройствами. Например, Mobile ID Authentication Module for Microsoft ADFS(github.com/FreddyKaiser/adfs-mobileid).
Роль AD FS должен выполнять сервер находящийся в защищенной внутренней сети, а WAP таким образом будет играть роль дополнительного барьера, не позволяя обращаться к AD FS из вне напрямую. Развернуть AD FS на одном сервере с WAP все равно не получится, мастер установки WAP обнаружив AD FS прерывает работу.
Поддержка технологии Single-Sign-On (SSO) позволяет после подключения к домену больше не вводить пароль для доступа к разрешенным приложениям.
Для приложений не поддерживающих AD FS аутентификацию предусмотрен вариант Pass-through preauthentication, когда предварительная аутентификация средствами AD FS не производится, соединение просто пробрасывается дальше, а сам процесс распознавания пользователя целиком ложится на приложение. Такой вариант может понадобиться, например, если сервис не поддерживает все новые функции AD (CBA, например). Для таких подключений естественно не будут доступны Workplace Join, MFA и мультифакторный контроль доступа. В случае Pass-through preauthentication при развертывании достаточно чтобы сервер с ролью WAP был присоединен к домену. Но учитывая, что WAP без AD FS все равно работать не будет (ведь по сути это прокси) все равно придется разворачивать и AD FS.
WAP не имеет интегрированных функций балансировки нагрузки, но проблема легко решается за счет использования встроенной роли Windows Load Balancing.
Особо стоит отметить, что никаких дополнительных лицензий клиентского доступа (CAL) при развертывании WAP не требуется, все что нужно будет приобрести это лицензию на собственно Windows Server 2012R2.

Подготовка к развертыванию

Самый большой плюс WAP состоит в том, что он является встроенной ролью, а не отдельным приложением, которое нужно установить и настроить. Предшественники TMG и UAG не были простыми в развертывании и часто сам процесс не редко требовал серьезного «напилинга» и чтения документации в поисках причин выдаваемых ошибок. Только на подготовку ОС заключающуюся в поиске и установке всех нужных патчей и зависимостей могла занять более часа. Последующая конфигурация приложений тоже было дело не совсем простым и часто требовало как минимум дня, чтобы все заработало как нужно. В этом отношении WAP выглядит очень простым и дружелюбным.
Веб-прокси следует развертывать в демилитаризованной зоне (DMZ) между брандмауэром выходящим в интернет и корпоративной сетью. Теоретически можно устанавливать WAP на сервере с другими ролями, но это не рекомендуется и лучше выделить под него отдельный сервер. Саму ОС лучше ставить с GUI (хотя желание отключить графику при установке такого сервера конечно же понятно), при развертывании будут доступны мастера которые помогут быстро произвести все установки. При подключении с другого сервера, бывают неувязки (в основном наблюдались в релизе, после нескольких патчей работает уже нормально). Хотя вообщем все вопросы администрирования можно решить при помощи PowerShell.
Системные требования для сервера не велики, поэтому подойдет минимальное железо удовлетворяющее развертыванию самой ОС. Перед установкой WAP необходимо подключить сервера AD FS и WAP к домену (схему нужно обязательно повысить до Windows Server 2012 R2), сгенерировать сертификаты (для каждого сервера и по одному для каждого приложения) и настроить AD FS.
Предположим у нас уже есть SSL сертификаты (шаблон Web Server вполне подходит) в поле Subject Alternative Name которого содержится DNS имя публикуемой службы AD FS и WAP. Импортируем их на сервера AD FS и WAP через консоль MMC Сертификаты.

Развертывание AD FS

Начинаем с AD FS. Вызываем Диспетчер сервера > Мастер добавления ролей и отмечаем роль Active Directory Federation Services или вводим в консоли PowerShell команду:

	PS> Install-WindowsFeature ADFS-Federation –IncludeManagementTools

Далее все стандартно. По окончании установки, в последнем окне мастера будет предложено произвести настройку службы федерации, так же ссылка появится в виде предупреждения в Диспетчере сервера.

Мастер настройки службы федерации Active Directory

Мастер настройки службы федерации Active Directory

Установки мастера вообщем понятны. Так как у нас сервер AD FS пока единственный, выбираем на первом шаге “Создать первый сервер федерации в новой ферме” и пишем учетную запись для подключения. Далее выбор сертификата, который будет использоваться для шифрования. Если он уже импортирован, то просто его находим в раскрывающемся списке. Можно импортировать сертификат и в окне мастера, но он понимает лишь формат PFX. Поэтому если удостоверяющий центр прислал в другом формате придется вначале его конвертировать. Когда сертификат выбран, автоматически заполняется DNS имя службы федерации, которое будут использоваться клиентами при подключении. Далее указываем имеющуюся или создаем новую учетную запись для службы AD FS. Во втором варианте при дальнейшем конфигурировании обычно появляется ошибка. Решение проблемы выдается сразу в сообщении. Обычно требуется сгенерировать корневой ключ к целевому контроллеру домена, для чего нужно выполнить:

	PS> Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

После чего повторяем работу мастера. Дополнительный параметр «-EffectiveTime (Get-Date).AddHours(-10)» вводит ключ в действие немедленно (по умолчанию через ~10 часов).
Хранение конфигурации AD FS возможно во внутренней базе данных (Windows Internal Database, WID) или SQL сервере. WID поддерживает ферму до 5 серверов AD FS, но в этом случае не обеспечивается отказоустойчивость и некоторые продвинутые механизмы работы службы. Но для небольших сетей WID вполне достаточно.
Обычно хватает варианта предложенного по умолчанию. Если проверка условий не показала ошибок, можно нажимать кнопку Настроить. Настройка при помощи PowerShell выглядит просто:

	PS> Install-AdfsFarm -CertificateThumbprint '123...0067' -FederationServiceName adfs.example.org -GroupServiceAccountIdentifier EXAMPLE\adfs$

Для проверки работоспособности открываем консоль AD FS и смотрим статус.

Развертывание WAP

Теперь когда служба ФВ FS работает, можем приступать к установке роли WAP. Вызываем мастер выбираем роль Remote Access и на этапе выбора служб ролей отмечаем Web Application Proxy, подтверждаем выбор дополнительных компонентов и устанавливаем.

Установка роли Web Application Proxy

Установка роли Web Application Proxy

После выбора Remote Access может появиться ошибка о “возможном несоответствии компьютера”, просто перезапускаем мастер, обычно второй раз она не появляется.

	PS> Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools

По окончанию запускаем мастер настройки WAP. В первом окне вводим имя и учетную запись администратора сервера AD FS. Далее указываем сертификат для WAP и подтверждаем настройки. В последнем окне мастера можно увидеть PowerShell команду которая будет выполнена.

	PS> Install-WebApplicationProxy –CertificateThumprint '23...567' -FederationServiceName adfs.example.org

Настройка завершена. В процессе на стороне служб ADFS создается подписка на WAP сервер.

Настройка Web Application Proxy

Настройка Web Application Proxy


В интернет можно поискать готовые PowerShell скрипты(goo.gl/LMSO9j) позволяющие развернуть связку AD FS + WAP в считанные минуты.
Проверяем статус. Открываем консоль Remote Access Management Console и переходим в Web Application Proxy и смотрим в Operations Status. Иногда в консоли один и тот же сервер показывается дважды: для доменного имени и NETBIOS. Это не ошибка, а очевидно такая фича.
Теперь ни что не мешает опубликовать сервис. Нажимаем Publish и следуем указаниям визарда. Первый шаг выбор метода преаутентификации, здеcь два варианта о которых мы говорили в самом начале: AD FS и Pass-through. Первый вариант содержит на один шаг больше. Выбираем Pass-through.

Выбор метода преаутентификации

Выбор метода преаутентификации

Следующий шаг – задаем имя публикуемого приложения, используемый сертификат, внешний URL, который будут использовать для подключения клиенты и URL приложения на который будут пересылаться запросы. Если бэкэнд использует нестандартный порт, то его также указываем вместе именем (https://service.example.org:8080).
Есть еще тонкий момент. Веб-прокси различает и транслирует имена хостов, но не понимает IP и не может изменить путь. То есть если внешний URL выглядит как https://service.org/app1/, то и URL бэкэнда должен содержать app1 т.е. https://service.example.org/app1/. Другой путь вроде https://service.example.org/web-app/ будет неправильным.
Публикация приложения окончена. Теперь, можно протестировать зайдя с помощью браузера по внешнему адресу, пользователь после успешной аутентификации на WAP будет перенаправлен на внутренний сайт.
В случае выбора аутентификации средствами AD FS появляется дополнительный шаг, на котором следует указать механизм доверия (Get-ADFSRelyingPartyTrust) – Device Registration Service, WS-Fed, SAML, OAuth.
Для варианта с аутентификацией с AD FS следует создать доверие на сервере AD FS. Открываем консоль AD FS и переходим в Отношения доверия (Trust Relationships) нажимаем «Добавить отношения доверия с проверяющей стороной не поддерживающей утверждения» (Add Non-Claims-Aware Relaying Party Trust).

Работа мастера настройки отношения доверия

Работа мастера настройки отношения доверия

Далее следуем указаниям интуитивного мастера – указываем имя, добавляем идентификатор доверия (обычно используют внешний URL, только имя должно быть со слэшем в конце), настраиваем многофакторную аутентификацию и подтверждаем установки. По окончании можем отредактировать правила авторизации (Authorization Rules). В окне “Edit Claim Rules for …” нажимаем “Add Rule” и указываем шаблон правила наиболее подходящий для ситуации (например, Permit All Users) и на следующем шаге при необходимости его редактируем.

Новое в следующем релизе WAP

За время с момента появления WAP он был развернут во многих компаниях и стали очевидны некоторые моменты, усложнявшие настройку. Все это будет исправлено в следующей версии WAP, познакомиться с которой можно в недавно анонсированной Windows Server 2016. Кроме изменений в интерфейсе управления WAP появилась множество новых функций. Например, возможность преаутентификации AD FS при подключении HTTP Basic (HTTP Basic preauthentication), когда учетные данные отправляются в самом запросе (такой вариант например используется в Exchange ActiveSync). Вся необходимая информация AD FS извлекается из URL автоматически и если пользователь подтверждается, то выдается действительный маркер (Claim), который дополнительно помещается в кэш, чтобы лишний раз не нагружать сервер. Этот вариант имеет специальный режим работы HTTP Basic preauthentication with certificates, позволяющий проверить сертификат устройства и убедиться, что оно зарегистрировано в Device Registration Service и разрешено к использованию в организации. Также появилась возможность просто публиковать не только домен, но и субдомены, причем даже все разом, по шаблону (https://*.example.org/). Такая функция очень упрощает публикацию приложений SharePoint, которые используют субдомены.
Кроме того, разрешена публикация внешнего URL по протоколу HTTP, в предыдущей версии по причинам безопасности от этого отказались, но в процессе эксплуатации выяснилось HTTP в некоторых конфигурациях все таки нужен. Также реализован автоматический редирект HTTP запроса поступившего на внешний URL в HTTPS. Для аудита и корректной работы приложения часто требуется знать оригинальный IP, теперь при перенаправлении он сохраняется в X-Forwarded-For.
В обновлении к WAP в Windows Server 2012R2 появилась возможность публикации Remote Desktop Gateway и теперь сотрудники могут без проблем подключаться к рабочим столам через RD Web Access, а администраторам упрощается процесс развертывания и сопровождения удаленного доступа. В новой версии WAP эта возможность уже штатная.

Вывод

Появление Web Application Proxy в Windows Server 2012 R2 позволило публиковать внутренние приложения без использования сторонних решений, а сам процесс внедрения WAP обычно не занимает много времени.

Теги: , ,

Понравилась статья? Оставьте комментарий или подпишитесь на RSS рассылку.

Комментарии

Комментариев пока что нет

Оставить комментарий

(required)

(required)