Web Application Proxy
В этой статье мы рассмотрим, как в Windows Server 2016, для получения доступа к информации из любого места, можно использовать обновлённый Web Application Proxy.
Содержание:
Web Application Proxy и новые возможности публикации
Пользователи могут получить доступ к данным компании с помощью различных устройств, например, портативных компьютеров, планшетов и смартфонов. С этих устройств можно отправлять запросы из любого места, но пользователи ожидают иметь тот же функционал, к которому они привыкли находясь на своей территории. IT должно гарантировать, что весь канал связи защищён, от данных, находящихся в центре обработки (на месте или в облаке), до данных в пути к целевому устройству. Там, они также должны быть защищены.
Чтобы предоставить пользователям безопасный доступ к данным компании, Web Application Proxy в Windows Server 2016 был расширен, охватывая больше сценариев с приложением (BYOD), например Pre-Auth с Microsoft Exchange Server. Web Application Proxy, для аутентификации и авторизации, по-прежнему используют Active Directory Federation Services (AD FS) и AD DS.
Эта интеграция очень важна для BYOD сценариев, потому что даёт возможность создавать свои пользовательские правила для локальных пользователей, отличные от тех, что даются через Интернет.
Примечание. Если вы не знакомы с Web Application Proxy в Windows Server 2012 R2, читайте статьи на
Опыт установки Web Application Proxy аналогичен предыдущей версии Windows Server 2012 R2. Таким образом для его установки в Windows Server 2016 можно использовать те же шаги. После завершения установки, вам предлагается выполнить конфигурацию после развёртывания.
Конфигурация после развёртывания для Web Application Proxy
Примечание. Перед развёртыванием Web Application Proxy, убедитесь, что вы спланировали инфраструктуру согласно рекомендациям из статьи на . Эта статья была написана для Windows Server 2012 R2, но рекомендации по-прежнему применяются к Windows Server 2016.
Когда вы закончите шаги post-deployment, которые в основном подключают Web Application Proxy для сервера AD FS, можно использовать Publish New Application Wizard. Вы заметите, что в этой новой версии были введены некоторые изменения. Первое изменение вы увидите при нажатии кнопки "Опубликовать", под инструментом управления Web Application Proxy (параметры доступны в левой панели). Например на странице предварительной проверки подлинности, вы можете выбрать либо Active Directory Federation Services (AD FS) или метод предварительной аутентификации Pass-Through.
Выбор предварительной проверки подлинности
В этом примере, как метод предварительной проверки подлинности, выберите Active Directory Federation Services (AD FS) и затем нажмите кнопку «Далее». На странице Supported Clients ваши варианты -- Web And MSOFBA, HTTP Basic или OAuth2.
Поддерживаемые клиенты
Чтобы выполнять предварительную проверку подлинности клиентов с использованием протокола Microsoft Office Forms Based Authentication (MSOFBA), можно использовать параметр Web and MSOFBA. MSOFBA при использовании клиентских приложений Office, обеспечивает проверку подлинности на основе форм базовой или NTLM аутентификации. Второй вариант - базовая проверка подлинности HTTP, которую можно использовать в таких сценариях, как Exchange Active Sync (ActiveSync). Это новые, добавленные в этот выпуск Web Application Proxy, возможности.
Для сценария, ActiveSync процесс аутентификации включает четыре основных этапа:
- WAP, останавливает запрос и передаёт все учётные данные AD FS.
- AD FS проверяет, применяет политику и отвечает с маркером.
- После успеха Web Application Proxy разрешает передачу запроса на сервер Exchange.
- Web Application Proxy кэширует маркер для будущего использования.
Третий вариант — OAuth2, который является основой авторизации многих производителей, включая Microsoft. Web Application Proxy поддерживает OAuth2 с Windows Server 2012 R2. Однако параметр не был доступен в пользовательском интерфейсе (UI).
Подробнее. Чтобы узнать больше о OAuth2, перейдите на . Вы можете найти дополнительную информацию о поддержке AD FS для OAuth2 на .
После того, как вы выберите соответствующего клиента для публикации, нажмите кнопку «Далее». Страница "Параметры публикации" включает в себя одну новую опцию, где вы можете включить перенаправление HTTP на HTTPS.
Параметры публикации
Это большое дополнение, так как чтобы включить перенаправление HTTP на HTTPs в Windows Server 2012 R2, необходимо установить и настроить Internet Information Services (IIS). Обратите внимание, что этот параметр отмечен по умолчанию. Но, перед нажатием кнопки "Дальше" и переходом к странице подтверждения, убедитесь, что он выбран для вашего приложения.
Сценарии Remote Desktop Gateway
Изменения, которые впервые были сделаны в пакете обновления Windows Server 2012 R2 августа 2014, относительно того как Web Application Proxy обрабатывает публикации Remote Desktop Gateway, включены в этом выпуске. Это изменение упрощает процесс развёртывания для ИТ-администраторов, которые планируют публиковать RDP через Web Application Proxy и позволяет Remote Desktop Gateway собирать использованный Remote Desktop Web Access для аутентификации трафика RDP через HTTP, файл cookie сеанса.
Аудит доступа к ресурсам
Windows Server 2016 вводит новые возможности, что позволяет администраторам улучшить аудит доступа к опубликованным ресурсам. Теперь Web Application Proxy, чтобы проверить существует ли заголовок X-Forwarded-For (XFF), добавляет его каждому запросу. Если это так, Web Application Proxy связывает IP клиента с этим заголовком.
Примечание. XFF это нестандартный заголовок HTTP, который стал стандартом де-факто. Он широко используется с прокси-серверами для определения IP возникающего запроса. Дополнительные сведения об этом прочитайте на .
Ещё один важный аспект Web Application Proxy - возможность аудита событий, которые регистрируются в Event Viewer. В этом выпуске средство просмотра событий включает в себя множество событий, таких как журналы отладки и аналитики.
Применение прокси приложений в современном мире ИТ
Несколько лет назад у нашей команды была большая дилемма. У нас на рынке было два продукта: Forefront Threat Management Gateway и Forefront Unified Access Gateway. Оба эти продукта существовали в течение многих лет и были развёрнуты десятками тысяч клиентов. Оба они развивались с тех пор, как были впервые представлены в 1990-х годах.
Однако оба продукта имели схожие проблемы: они были очень сложными, сложными для развёртывания, устранения неполадок и обслуживания. Отчасти это было потому, что за эти годы они накопили много возможностей, которые стали неуместными. В то же время не хватало или имелась ограниченная поддержка современных технологий, таких как OAuth2. Вдобавок ко всему, это были дорогие продукты, со своими лицензиями.
Это было жёсткое решение, но мы решили начать с чистого листа, изучить все функции обратного прокси, выбрать и отобрать только те технологии, которые имеют значение сегодня, и реализовать их, используя новую базу кода, построенную на большинстве современных стандартов. Основная часть этого решения заключалась в том, что мы хотели встроить в Windows Server обратный прокси. Мы хотели сделать это точно так же, как и любую другую службу роли, доступной для установки из диспетчера сервера. Для нас это означало соблюдение самых строгих стандартов в отношении кода и управления. Клиенты Microsoft ожидают, что все службы роли Windows Server будут управляться одинаково, в том числе в Windows PowerShell, пользовательский интерфейс администратора, удалённый пользовательский интерфейс администратора, счётчики производительности, пакет System Center Operations Manager, журналы событий и т. д.
Именно так в Windows Server 2012 R2 появился Web Application Proxy. Мы не делали компромиссов по обеспечению безопасности кода, управлению и стандартизации. И мы были счастливы, что клиенты получили его. Компании смогли легко внедрить и интегрировать Web Application Proxy в свою инфраструктуру.
Недостаток этого подхода в том, что мы не смогли включить все функциональные возможности, которые хотели иметь - функциональность, которая позволила бы всем клиентам перейти с Threat Management Gateway и Unified Access Gateway к новому решению. Однако теперь, когда мы создали прочную основу, стало проще добавить больше функциональности, чтобы сделать Web Application Proxy очевидным выбором для публикации локальных ресурсов, таких как Microsoft SharePoint, Lync и Exchange удалённым пользователям. Эта версия знаменует важную веху в путешествии, которое мы начали довольно много лет назад.
Теперь пришло время начать ещё одно путешествие и обеспечить удалённый доступ к облачной эре. В качестве другого инструмента для публикации пользователями приложений в облачных решениях, мы создали Azure Active Directory Application Proxy. К счастью, Web Application Proxy в Windows Server и Azure Active Directory Application Proxy используют много кода. Более того, они используют одни и те же концепции и восприятие удалённого доступа, делая их простыми в развёртывании и лёгкими в поддержке.
В будущем мы продолжим развивать оба продукта. Мы планируем предложить заказчикам Microsoft выбор в использовании архитектуры. Облако предлагает пользователям уникальный и высокоэффективный способ реализации удалённого доступа, с использованием богатых функциональных возможностей и надёжных механизмов безопасности Azure Active Directory, без необходимости изменения их периметрической сети. Тот же сервис, который обслуживает 18 миллиардов запросов на проверку подлинности в неделю, обрабатывает ваши локальные приложения.
Меир Менделович, старший менеджер программы
