Что такое wap сервер
Что такое WAP?
WAP (Wireless Application Protocol), или (Wireless Access Protocol) — «протокол беспроводного доступа» — это средство получения доступа к ресурсам Интернет посредством только мобильного телефона, не прибегая к помощи компьютера и/или модема. По сути это технический стандарт, описывающий способ, с помощью которого информация из Интернет передается на дисплей мобильного телефона.
Теоретически, если бы экран мобильного телефона смог отобразить то многообразие информации, что и дисплей компьютера, то WAP ничем не отличался бы от отображения обычных WEB-страниц. Но так как разрешение экрана дисплея мобильного телефона невелико, и скорость передачи данных по каналам связи довольно мала, отображение WAP-сайтов отличается недостаточной графикой и анимацией, а объем информации сведен к необходимому минимуму.
Так что же нужно, чтобы пользоваться WAP?
Необходимо иметь три вещи, а именно:
WAP-броузер
С появлением WAP-протокола абоненты сотовых сетей получили возможность пользоваться рядом сервисных услуг на специальных WAP-сайтах, таким, как:
Во всемирной сети с каждым днем появляется все больше и больше WAP-ресурсов. Для многих популярных Web-сайтов созданы их WAP-близнецы, которые предоставляют «мобильным» пользователям тот же набор услуг. Например сайт электронной почты http://www.mail.ru/ имеет WAP-версию http://wap.mail.ru/. Для тех, кто хочет оценить тот или иной WAP-сайт не отходя от своего компьютера, существуют WAP-эмуляторы, которые позволяют воспроизвести работу с WAP на дисплее мобильного телефона.
Более полныый список WAP-эмуляторов dubna.com Online Web Emulator WinWap Phone.com Developer Web Site PyWeb.com Deck-It Previewer TTemulator — WAP phone emulator
Операторы
И третье обязательное условие для использования WAP — это поддержка Вашим оператором мобильной связи услуги предоставления мобильного Интернета. Большинство российских операторов сегодня предоставляют эту услугу. Все, что Вам необходимо — это понять нужен ли Вам WAP, узнать тарифы оператора на услугу передачи данных и включить ее в обслуживание. Осталось только определиться, а нужен ли Вам WAP, в том виде, в котором он существует сейчас?
Перспективы WAP
С внедрением WAP открылись его достоинства и недостатки. Ведь для отображения информации на экране сотового телефона используется, как правило, четыре строки. Главный принцип предоставления WAP-информации на сотовый телефон — разбиение данных на небольшие блоки размером в два-три экрана телефона. Не говоря уже о том, что интерфейс WAP оставляет желать лучшего, информацию содержащую до сотни символов приходится долго «листать», а при малой скорости передачи данных этот процесс затягивается. В результате полученная информация может оказаться неоправданно «дорогой», так как за минуты надо платить…
И у специалистов, обслуживающих WAP, возникают некоторые проблемы. Сайты, которые могут посещать пользователи с мобильных телефонов, надо постоянно адаптировать. Иными словами, WAP-сайт, который можно посмотреть на 8-строчном дисплее, для 4-х строчного уже не подходит, и его надо переписывать в специальной версии.
Поэтому, на сегодняшний день набор русских WAP-ресурсов остается скромным — в основном это погода, анекдоты, гороскопы, новости, курсы валют и афиши. На странице http://www.wapgate.ru/ все русские «мобильные странички» рассортированы по девяти темам: досуг/развлечения, мобильная коммерция, медицина/здоровье, операторы связи, СМИ/новости, справочная информация, туризм и отдых, WAP-сервис. На http://wap.uptsoft.com/ можно поиграть в «Морской бой» или «Крестики-нолики», воспользоваться русско-английским или англо-русским переводчиком на http://wap.translate.ru/, поискать нужный ресурс на http://wap.yandex.ru/, и даже початиться на http://wapchat.ru/.
Еще одним направлением WAP могут стать корпоративные решения. Существует много крупных компаний, у которых большому количеству мобильно передвигающихся менеджеров постоянно требуется какая-то информация. Технологии e-mail и SMS не могут покрыть их потребности, так как и в том и в другом случае информация посылается не по запросу клиента, а по решению серверной стороны.
Развитие WAP-технологий будет зависеть от того, как будет воспроизводиться объем разнообразной информации. Ведь ввод поддержки новой технологии пакетной передачи данных GPRS (General Packet Radio Service) существенно повысит скорость работы с WAP-приложениями.
Востребована она будет или нет, покажет рынок. Далее, возможны работы по построению шлюзов по преобразованию стандарта HTML (на котором построены традиционные странички Интернета) в WML (стандарт для WAP-страничек). Это позволит абонентам использовать обычные ресурсы Сети и придаст большой скачок трафику.
Объективная оценка такова: WAP-технология в ее современном виде является пока переходным решением. Разработчики уже модернизируют его, избавляя от первоначальных недостатков. Возможно, изменятся цели, которые достигаются применением WAP. Однако общая идея предоставления информации из Интернет на мобильный телефон будет только развиваться. Появляются новые мобильные телефоны и смартфоны — гибриды телефонов и карманных компьютеров и в дальнейшем, вероятно, прямо на своем мобильнике или смартфоне можно будет «путешествовать» по настоящему Интернету.
Кое-что о WAP
Сегодня возможности сотовых телефонов просто огромны, и с каждым днем они только увеличиваются. А если учесть, что компании, производящие сотовые телефоны, выкидывают на рынок не по одной новинке в месяц, то уследить за всеми новшествами практически невозможно. Да это и не нужно. Достаточно вовремя узнавать о действительно глобальных и перспективных нововведениях.
WAP (Wireless Application Protocol)
Сколько шума было, да и есть, вокруг этой технологии. Так же, как когда-то вокруг системы спутниковой связи Iridium. Вот только мы знаем, что стало с этим проектом…
Использовать открытие обыкновенных HTTP страниц через сотовый телефон неудобно тем, что на таких страницах большие заголовки (вспомните размер дисплея вашего сотового телефона), отсутствие протокола сжатия, слишком большой объем служебной информации и многое другое. WAP же страницы используют двоичный стандарт, позволяющий сжимать пакеты данных, они менее насыщены графической информацией и т.д.
И кстати. Говоря о WAP, нельзя не упомянуть и о таком протоколе, как GPRS. О нем у нас будет отдельный разговор, но не упомянуть об этом сейчас просто нельзя…
В общем, критики полно. Самое неприятное, что она раздается и в рядах самих создателей данной технологии. Так называемый WAP Forum, руководящий проектом и следящий за его развитием, неожиданно получил критиков в своих же рядах. В частности, Дэвид Ренсин, технический директор компании Aether Systems, разрабатывающей инфраструктуру Internet-доступа для портативных устройств, заявил на конференции Mobile Insights о «смерти WAP». Это заявление было настолько неожиданным, что многие впали чуть ли не в панику. Конечно, не стоит принимать такие заявления как пророческие, но призадуматься о срочности покупки сотового телефона, оснащенного WAP-броузером, несомненно, стоит…
Чтобы скрасить картину, упомянем о том. что WAP совместим с большим количеством транспортных протоколов и с такой перспективной технологией, как Bluetooth. К тому же, уже сегодня ведутся разработки технологий, дополняющих WAP. Например, технология ScoutWeb компании Aether дополняет WAP, чтобы адаптировать Web-сайты для PDA (personal digital assistant) и сотовых телефонов…
Скорее всего, масштабного прорыва, вот так сразу, не будет. Точнее, не было. Слишком мало WAP-сайтов, слишком мало телефонов (по сравнению с простыми сотовыми телефонами), слишком дорого это стоит, слишком… слишком много этих «слишком»…
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 (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:
В практических демонстрация будут использоваться оба типа, так как пока не все публикуемые приложения Exchange поддерживают ADFS аутентификацию.
Требования к развертыванию Web Application Proxy
Описание лабораторного стенда
Исследование WAP будет выполнено на лабораторном стенде, работающем под управлением Windows Server 2012 R2 Datacenter с установленной ролью Hyper-V. На сервере создано 3 виртуальных коммутатора: WAN, LAN и DMZ.
Ниже представлена упрощенная топология стенда — WAP Network
В качестве маршрутизатора использовался Endian Firewall community, основанный на Linux. Маршрутизатор реализует «трехногую» конфигурацию, образовывая 2 частных сети DMZ и LAN.
Адресное пространство DMZ — 192.168.1.0/24, а для LAN — 172.16.20.0/24.
Весь процесс конфигурирования разбит на логические части, каждая представляет отдельную статью, ниже список:
WAP: экскурс в историю протокола
WAP (Wireless Access Protocol) – это устаревший протокол для беспроводного доступа к сети, ориентированный на использование для этого мобильных телефонов. Основной задачей данной технологии являлось решение проблемы загрузки « тяжелого » контента с обилием графики и анимации. Она просто отсутствовала в контенте WAP-сайтов. Также ВАП-протокол отображал на экране телефона сайты, адаптированные к размерам дисплея и низкому разрешению. Достигалось это за счет того, что сайты, созданные для передачи с помощью стека протокола WAP, не содержали никаких лишних графических элементов и другого ресурсоемкого контента. Данные в нем передавались в виде байт-кода, что позволяло загружать страницы быстро.
Как работает WAP
WAP базируется на целой группе интернет-протоколов и спецификаций: HTTP, UDP, URL, HTML и JavaScript. В протоколе WAP ведущую роль играет понятие URL, в этом модель адресации ВАП практически идентична адресации в привычном интернете. Прикладной уровень протокола WAP состоит из четырех частей — модели адресации (The Addressing Model), языка Wireless Markup Language (WML), языка WMLScript и приложения Wireless Telephony Application (WTA).
Язык разметки WML основан на XML, но значительно упрощен по сравнению с последним. WML учитывает ограничения старых мобильных устройств (небольшой размер экрана, объем памяти и т.д.). Конечно, отличия между WML и XML есть, и они немалые, но сам принцип работы и логика программирования одинаковы. В свою очередь язык программирования WMLScript, используемый при создании ВАП-сайтов, основывается на спецификации ECMAScript, которая является стандартом для JavaScript. Последняя часть прикладного уровня — WTA — позволяет создавать всевозможные сервисы на базе протокола WAP. Например, записывать информацию с WAP-сайта непосредственно в адресную книгу телефона.
От версии к версии
Еще на заре возникновения сотовой связи производители мобильных телефонов и операторы связи задумались об оптимизации предоставления услуг по передаче данных. Правда, тогда речь шла не о доступе к Интернету, а о работе классических приложений, способных обмениваться данными с офисными компьютерами. В 1995 году компания Ericsson начала разработку протокола ITTP (Intelligent Terminal Transfer Protocol), который должен был значительно расширить число сервисов, предоставляемых сотовым телефоном. В этом же году компания Unwired Planet, позже переименованная в Phone.com, предложила протокол связи для сетей DAMPS (CDPD) и iDEN, реализованный на базе языка HDML (Handheld Device Markup Language), основанный на общепринятом языке разметки документов HTML. В 1996 году компания Nokia начала внедрять собственный проект развития передачи и обработки данных по беспроводным сетям.
В конце 1997 года эти фирмы поняли, что появление нескольких конкурирующих между собой стандартов и протоколов может полностью погубить зарождающийся рынок услуг по передаче данных с помощью сотовых телефонов. Именно поэтому Ericsson, Motorola, Nokia и Unwired Planet объединили свои усилия и создали WAP Forum — специальную организацию, занимающуюся разработкой и развитием протокола WAP. В скором времени участниками проекта стали крупные производителей инфраструктуры сотовой связи и мобильной телефонии.
В результате активных действий разработчиков в мае 1998 года появилась первая версия протокола WAP — v.1.0. Несмотря на стройность общей концепции, проект получился сырым. В результате протокол так и не был внедрен, прекратив свое существование на уровне тестирования. В июне 1999 года была представлена вторая версия — WAP v.1.1. Летом 2000 года были обнародованы WAP v.1.2 и его подвид WAP v.1.2.1. Последняя версия WAP v.2.0 появилась в январе 2002 года.
WAP 2.0 — усовершенствованная версия WAP, которая использовала сокращенный вариант CSS, благодаря чему сайт мог быть открыт и с помощью обычного браузера на компьютере без установки каких-либо дополнительных плагинов и приложений.
WAP-сайты и WAP-хостинги
Хостинг WAP-сайтов ничем не отличался от хостинга «обычных » веб-ресурсов. В классической схеме взаимодействия запрос от браузера пользователя напрямую поступает на сервер провайдера. Там он идентифицируется, обрабатывается и происходит обратная передача необходимых данных в пакетном виде. При использовании протокола ВАП в этой схеме дополнительно задействовался шлюз-ретранслятор. Он располагался между беспроводной сетью и клиентом, играя роль прокси-сервера. Также он кодировал информацию в байт-код и обратно. Когда WAP-устройство выполняло подключение к WAP-хостингу, оно уведомляло сервер, что необходима мобильная версия сайта в формате WAP. Сервер же автоматически предоставлял упрощенную форму запрашиваемой страницы.
Стек протокола WAP состоял из пяти основных уровней: Wireless Application Environment (WAE), Wireless Session Protocol (WSP), Wireless Transaction Protocol (WTP), Wireless Transport Layer Security (WTLS) и Wireless Datagram Protocol (WDP). Кроме того, к ним обычно добавлялся еще один, зависящий от стандарта сети сотовой связи. Если сравнивать модель стека WAP и WEB, то окажется, что между ними много общего. Вспомогательный уровень стека соответствует IP, WDP — TSP, WTLS — TLS-SSL, WSP и WST — HTTP, WAE — HTML.
Для обычного пользователя принцип работы протокола WAP выглядит следующим образом: хостинг-провайдер предоставляет серверное пространство для хранения мобильной версии сайта. Пользователь отсылает запрос на открытие ВАП-сайта стандартным способом через WAP-браузер. В момент подключения к хостингу WAP-устройство уведомляет сервер, что необходима именно мобильная версия сайта. Хост-сервер обрабатывает запрос и автоматически предоставляет упрощенную форму запрашиваемой страницы.
Особенности технологии
С момента внедрения сотовыми операторами транспортного протокола передачи данных в беспроводной сети GPRS противники WAP заговорили о бесперспективности применения и дальнейшего развития данной технологии. Действительно, стандарт GPRS позволял легко загружать на мобильные устройства даже довольно тяжелые веб-ресурсы (если их можно сейчас таковыми назвать). Но у GPRS был один существенный недостаток – скорость соединения обратно пропорциональна количеству одновременных подключений пользовательских устройств к базовой станции. В моменты пиковых нагрузок страницы сайта начинали открываться медленно, возникали длительные таймауты и обрывы соединений. WAP-ресурсы, в силу небольшого объема передаваемых данных, практически не зависели от скорости интернет-соединения.
Главным принципом предоставления WAP-информации на сотовый телефон было разбиение данных на небольшие блоки размером в два-три экрана телефона, на которых отображалось не более восьми строк информации. В результате интерфейс ВАП-браузера выглядел очень примитивно, а для прочтения информации, содержащей сотни символов, страницу сайта приходилось очень долго пролистывать. Кроме того, одним из существенных минусов использования WAP была высокая стоимость трафика, передаваемого по этому протоколу.
Знакомимся с 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. Во втором варианте при дальнейшем конфигурировании обычно появляется ошибка. Решение проблемы выдается сразу в сообщении. Обычно требуется сгенерировать корневой ключ к целевому контроллеру домена, для чего нужно выполнить:
После чего повторяем работу мастера. Дополнительный параметр «-EffectiveTime (Get-Date).AddHours(-10)» вводит ключ в действие немедленно (по умолчанию через
10 часов).
Хранение конфигурации AD FS возможно во внутренней базе данных (Windows Internal Database, WID) или SQL сервере. WID поддерживает ферму до 5 серверов AD FS, но в этом случае не обеспечивается отказоустойчивость и некоторые продвинутые механизмы работы службы. Но для небольших сетей WID вполне достаточно.
Обычно хватает варианта предложенного по умолчанию. Если проверка условий не показала ошибок, можно нажимать кнопку Настроить. Настройка при помощи PowerShell выглядит просто:
Для проверки работоспособности открываем консоль AD FS и смотрим статус.
Развертывание WAP
Теперь когда служба ФВ FS работает, можем приступать к установке роли WAP. Вызываем мастер выбираем роль Remote Access и на этапе выбора служб ролей отмечаем Web Application Proxy, подтверждаем выбор дополнительных компонентов и устанавливаем.
Установка роли Web Application Proxy
После выбора Remote Access может появиться ошибка о «возможном несоответствии компьютера», просто перезапускаем мастер, обычно второй раз она не появляется.
По окончанию запускаем мастер настройки WAP. В первом окне вводим имя и учетную запись администратора сервера AD FS. Далее указываем сертификат для WAP и подтверждаем настройки. В последнем окне мастера можно увидеть PowerShell команду которая будет выполнена.
Настройка завершена. В процессе на стороне служб 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 обычно не занимает много времени.