Первый вал. Знакомимся с Web Application Proxy на Win2012R2

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

Web Application Proxy (WAP, прок­си‑сер­вер веб‑при­ложе­ний) пред­став­ляет собой обратный (reverse) прок­си, поз­воля­ющий адми­нис­тра­тору пуб­ликовать при­ложе­ния для дос­тупа извне. Работа­ет WAP прос­то: сер­вер получа­ет на внеш­ний адрес HTTPS-зап­рос от кли­ента (в текущей вер­сии толь­ко HTTPS) и рет­ран­сли­рует его на внут­реннее при­ложе­ние по HTTP или HTTPS. За осно­ву WAP взя­та служ­ба роли AD FS Federation Service Proxy, решав­шая задачу frontend-сер­вера при раз­верты­вании служб федера­ции 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.

Роль 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 не тре­бует­ся, все, что нуж­но будет при­обрести, — это лицен­зия на собс­твен­но Win2012R2.

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

Са­мый боль­шой плюс 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-коман­ду:

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

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

Пос­ле чего пов­торя­ем работу мас­тера. Допол­нитель­ный параметр «-EffectiveTime (Get-Date).AddHours(-10)» вво­дит ключ в дей­ствие немед­ленно (по умол­чанию при­мер­но через десять часов).

Хра­нение кон­фигура­ции AD FS воз­можно во внут­ренней базе дан­ных (Windows Internal Database, WID) или SQL-сер­вере. WID под­держи­вает фер­му до пяти сер­веров AD FS, но в этом слу­чае не обес­печива­ется отка­зоус­той­чивость и некото­рые прод­винутые механиз­мы работы служ­бы. Но для неболь­ших сетей WID впол­не дос­таточ­но.

Обыч­но хва­тает вари­анта, пред­ложен­ного по умол­чанию. Если про­вер­ка усло­вий не показа­ла оши­бок, мож­но нажимать кноп­ку «Нас­тро­ить». Нас­трой­ка при помощи PowerShell выг­лядит прос­то:

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

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

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

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

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

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

В интерне­те мож­но поис­кать готовые PowerShell-скрип­ты, поз­воля­ющие раз­вернуть связ­ку 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), и на сле­дующем шаге при необ­ходимос­ти его редак­тиру­ем.

Командлеты PowerShell

Нас­трой­ками AD FS и WAP так­же мож­но управлять как при помощи соот­ветс­тву­ющей кон­соли, так и исполь­зуя коман­дле­ты PowerShell. При­чем мно­гие опе­рации удоб­нее про­изво­дить имен­но при помощи PowerShell. Для WAP доcтуп­но 12 коман­дле­тов модуля Web Application Proxy, в модуле AD FS их 105. При­меры некото­рых коман­дле­тов уже при­води­лись ранее. Пол­ный спи­сок мож­но получить, вве­дя

Мо­дуль ADFS раз­бирать не будем (см. врез­ку), оста­новим­ся толь­ко на Web Application Proxy. Коман­длет Add-WebApplicationProxyApplication поз­воля­ет пуб­ликовать при­ложе­ние, для Pass-through коман­да выг­лядит так:

Часть коман­дле­тов дает воз­можность быс­тро получить информа­цию:

• Get-WebApplicationProxyConfiguration — информа­ция о кон­фигура­ции WAP;
• Get-WebApplicationProxyHealth — ста­тус работы;
• Get-WebApplicationProxyApplication — показы­вает нас­трой­ки пуб­ликации при­ложе­ний;
• Get-WebApplicationProxyAvailableADFSRelyingParty — спи­сок WAP, дос­тупных на AD FS;
• Get-WebApplicationProxySslCertificate — информа­ция о при­вяз­ке SSL-сер­тифика­та.

При помощи коман­дле­тов лег­ко сме­нить сер­тификат на WAP-сер­вере, смот­рим спи­сок:

Ста­вим новый сер­тификат:

Пос­ле чего пот­ребу­ется переза­пуск WAP:

Сох­раня­ем в файл нас­трой­ки пуб­ликации при­ложе­ний и вос­ста­нав­лива­ем на дру­гом узле:

Ко­ман­длет Get-WebApplicationProxyConfiguration выда­ет ряд полез­ных нас­тро­ек WAP-сер­веров. Нап­ример, параметр ConnectedServersName содер­жит мас­сив WAP-сер­веров, под­клю­чен­ных к AD FS. Можем лег­ко добавить новый:

Вывод

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