Web Application Proxy в Windows Server 2012 R2

Продолжаем знакомиться с новыми возможностями ОС 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 аккаунта. Сделать это можно командой:

И, наконец, указать базу данных, в которой будет хранится информация: это может быть встроенная база на этом же сервере (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 и пр.

Настройка параметров прокси-сервера в Windows

В этой статье описывается настройка параметров прокси-сервера в Windows.

Оригинальная версия продукта: Windows 10 — все выпуски, Windows Server 2012 R2
Исходный номер КБ: 2777643

Домашние пользователи. Эта статья предназначена для использования агентами поддержки и ИТ-специалистами. Дополнительные сведения о настройке прокси-сервера на домашнем компьютере см. в следующей статье:

Аннотация

Для настройки Windows для подключения к Интернету с помощью прокси-сервера доступно несколько методов. Метод, который будет работать лучше всего для вас, зависит от типов приложений, которые вы используете.

Настройка параметров прокси-сервера с помощью протокола автоматического обнаружения веб-прокси (WPAD)

Рекомендуется использовать WPAD для настройки Windows для использования прокси-сервера в Интернете. Конфигурация делается с помощью DNS или DHCP. Он не требует параметров на клиентских компьютерах. Пользователи могут привозить компьютеры и устройства из дома или других мест и автоматически открывать конфигурацию прокси-сервера в Интернете.

Настройка параметров прокси-сервера в Internet Explorer или с помощью групповой политики

Если вы предпочитаете статически настраивать клиентские компьютеры с помощью параметров прокси-сервера в Интернете, используйте один из следующих методов:

• Настройка параметров в Internet Explorer вручную.
• Настройка компьютеров, присоединив к домену, с помощью групповой политики.

Приложениям, которые не получают параметры прокси в Internet Explorer, может потребоваться установить параметры в каждом приложении для настройки параметров прокси.

Файлы автоматической конфигурации прокси/автоматической конфигурации (PAC)

Параметры файловой конфигурации (PAC) прокси-сервера также можно настраивать вручную в Internet Explorer или с помощью групповой политики. При использовании приложений Microsoft Store тип приложения определяет, используются ли параметры прокси, полученные из файлов PAC. Кроме того, у приложения могут быть параметры для настройки параметров прокси.

Программное обеспечение клиента прокси/брандмауэра

Программное обеспечение клиента прокси/брандмауэра имеет определенный характер для бренда прокси-сервера, который вы используете. Шлюз microsoft Forefront Threat Management Gateway (TMG) 2010 является примером прокси-сервера, который может использовать клиентские программы для управления настройками прокси. Клиентское программное обеспечение прокси/брандмауэра, установленное в качестве драйвера LSP, не будет работать в Windows с любыми приложениями Modern/Microsoft Store, но будет работать со стандартными приложениями. Клиентское программное обеспечение прокси/брандмауэра, установленное в качестве драйвера WFP, будет работать с Windows во всех приложениях. Обратитесь к производителю прокси-серверов, если у вас есть другие вопросы об использовании клиентского программного обеспечения производителя вместе с Windows.

Клиентский инструмент брандмауэра TMG/ISA основан на LSP и не будет работать с приложениями Modern/Microsoft Store.

Параметр командной строки

Вы также можете настроить параметры прокси-сервера с помощью netsh winhttp set proxy команды. Этот параметр рекомендуется только для тестирования, так как его непросто развернуть. Команда должна выполняться по командной подсказке с помощью учетных данных администрирования. Мы не рекомендуем этот вариант для мобильных компьютеров. Причина в том, что большинство пользователей не могут изменить этот параметр при подключении к другой сети.

Дополнительная информация

Дополнительные сведения о настройке параметров прокси-сервера с помощью групповой политики см. в следующей статье:
Средства и параметры расширения обслуживания Internet Explorer

Поднять прокси-сервер для внешних подключений

1. Есть сервер на Windows Server 2012
2. Есть роутер, который раздает интернет на этот сервер
3. Если клиентский компьютер, находящийся за пределами сети.
4. Хочу использовать сервер как Proxy для клиентского ПК.

HandyCache пробовал. Локально работает, с клиентского компьютера не работает (с нужным проброшенным на роутере портом).
Полагаю что данного ПО и проброшенного порта недостаточно, а требуется установка/настройка каких-то служб.
Прошу помощи.

Поднять прокси-сервер без использования стороннего ПО
Необходимо поднять прокси сервер на windows server 2008 r2 без использования стороннего ПО.

Не работает Autodiscover для внешних подключений
Exchange 2013 SP1 Почта работает и уходит и приходит и OWA доступна в локальной сети и в.

Смена настройки параметра сети (использовать или не использовать прокси-сервер для локальных подключений)
Всем доброго дня! Опишу сложившуюся ситуацию: На работу постоянно хожу с домашним ноутом. У нас в.

Как поднять свой прокси сервер?
Как на своём компьютере поднять прокси сервер и чтобы к нему могли подключаться?

схему нарисуйте с адресами.

Конкретно командой не проверял, но на данный момент настроен Remote Access (Удаленный рабочий стол) и Remote App.
Всё работает. Так что сигнал до сервера доходит.

В таблицу доступа HandyCache добавил внешний IP клиента, но толку нет.

Вы добавляете разрешения на WAN на внутреннюю сеть класса С, а нужно их реальный IP адрес внешний, с помощью чего клиент вообще в инет попадает

Добавлено через 32 секунды
VPN сервер, тогда нужно чтобы у Вас или у клиента был реальный белый адрес, если серый, то хамачи, сервис dyndns в помощь

С хамачи идея понятна: компьютеры окажутся друг для друга в одной сети и тут HandyCache вроде как должна тогда заработать. Верно?

А через настройку службы штатными средствами Windows Server 2012 это не сделать аналогично Remote Desktop?

Клиент стучится на внешний IP роутера на порт 8888, на роутере установлена переадресация с данного порта на сервер.
На сервере настроена служба Remote Desktop, которая подхватывает сигнал с порта 8888 и даёт через авторизацию подключиться к системе как новому пользователю.

Знакомимся с 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

Установки мастера вообщем понятны. Так как у нас сервер 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

После выбора 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

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

Следующий шаг — задаем имя публикуемого приложения, используемый сертификат, внешний 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 обычно не занимает много времени.