Что такое web application proxy

Прокси-служба веб-приложения в Windows Server

применимо к: Windows server 2022, Windows server 2019, Windows server® 2016

Данный материал относится к локальной версии прокси-сервера веб-приложения. Сведения о безопасном доступе к локальным приложениям через облако см. в содержимом прокси-сервера приложения Azure AD.

В этом разделе описано, что нового и изменено в прокси веб-приложения для Windows Server 2016. Новые функции и изменения, перечисленные здесь, скорее всего, оказывают наибольшее влияние на работу с предварительной версией.

Новые возможности прокси веб-приложения

Предварительная проверка подлинности при публикации приложений HTTP Basic

HTTP Basic — это протокол авторизации, используемый многими протоколами, включая ActiveSync, для подключения полнофункциональных клиентов, включая смартфоны, с почтовым ящиком Exchange. Прокси веб-приложения обычно взаимодействует с AD FS с использованием перенаправлений, которые не поддерживаются клиентами ActiveSync. Эта новая версия прокси веб-приложения обеспечивает поддержку публикации приложения с помощью HTTP Basic, позволяя приложению HTTP получить отношение доверия с проверяющей стороной, не относящейся к утверждениям, для приложения с служба федерации.

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

для поддержки таких сценариев, как SharePoint 2013, внешний URL-адрес приложения теперь может содержать подстановочный знак, позволяющий публиковать несколько приложений из определенного домена, например https://*. sp-apps. contoso. com. это упростит публикацию SharePoint приложений.

Перенаправление трафика HTTP в HTTPS

Чтобы пользователи могли получить доступ к приложению, даже если в URL-адресе не введено значение HTTPS, прокси веб-приложения теперь поддерживает перенаправление HTTP в HTTPS.

Теперь можно опубликовать приложения HTTP, используя сквозную предварительную проверку подлинности.

Публикация приложений шлюза удаленный рабочий стол

Новый журнал отладки для улучшения устранения неполадок и Улучшенный журнал службы для полного аудита и улучшенной обработки ошибок

Улучшения пользовательского интерфейса консоль администратора

Распространение IP-адреса клиента в серверные приложения

Источник

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 и ключевые особенности:

Установка роли 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 и пр.

Источник

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.

Весь процесс конфигурирования разбит на логические части, каждая представляет отдельную статью, ниже список:

Источник

Working with Web Application Proxy

This content is relevant for the on-premises version of Web Application Proxy. To enable secure access to on-premises applications over the cloud, see the Azure AD Application Proxy content.

Web Application Proxy is a new Remote Access role service in Windows ServerВ® 2012 R2. Web Application Proxy provides reverse proxy functionality for web applications inside your corporate network to allow users on any device to access them from outside the corporate network. Web Application Proxy preauthenticates access to web applications using ActiveВ Directory Federation Services (ADВ FS), and also functions as an AD FS proxy.

Providing Access to Applications

Web Application Proxy provides organizations with the ability to provide selective access to applications running on servers inside the organization to end users located outside of the organization. The process to make the application available externally is known as publishing. Unlike traditional VPN solutions, when you publish applications through Web Application Proxy end users can gain access only to applications that you publish. However, Web Application Proxy can also be deployed with VPN as part of a Remote Access deployment in your organization. See Interoperability with other remote access products, below.

Publishing Applications

Web Application Proxy publishing enables end users to access their organization’s applications from their own devices, so that users are not limited to corporate laptops to do their work, they can use their home computer, their tablet, or their smartphone. In addition, end users are not required to install any additional software on their device to access published applications. Web Application Proxy can be used on clients with a standard browser, an Office client or a rich client using OAuth (for example Windows Store apps). Web Application Proxy serves as a reverse proxy for any application that is published through it and as such, the end user experience is the same as if the end user’s device connects directly to the application.

Accessing Applications

Web Application Proxy must always be deployed with AD FS. This enables you to leverage the features of AD FS, such as, single sign-on (SSO). This enables users to enter their credentials one time and on subsequent occasions, they will not be required to enter their credentials. SSO is supported by Web Application Proxy for backend servers that use claims-based authentication; for example SharePoint claims-based applications, and Integrated Windows authentication using Kerberos constrained delegation. Integrated Windows authentication-based applications can be defined in AD FS as relying party trusts which can define rich authentication and authorization policies that are enforced in requests to the application.

Protecting Applications from External Threats

Web Application Proxy serves as a barrier between the Internet and your corporate applications. In many organizations, when you deploy Web Application Proxy and publish applications through it, those applications will be available to external users on devices that are not joined to your domain; for example, personal laptops, tablets, or smartphones. These devices are not domain-joined and as such, they are described as unmanaged devices, and are untrusted within the corporate network. Since you want your users to be able to access important information whenever and wherever they are located, you must mitigate the security risk of allowing users access to corporate resources from these unmanaged and untrusted devices. Web Application Proxy provides a number of security features to protect your corporate network from external threats. Web Application Proxy uses AD FS for authentication and authorization to ensure that only users on devices who authenticate and are authorized can access your corporate applications.

Defense in Depth

In the recommended deployment, Web Application Proxy is deployed in a perimeter network between an Internet-facing firewall and a corporate network firewall. However, in addition to the protection provided by the firewalls themselves, Web Application Proxy provides additional protection for your applications from external threats.

When HTTPS traffic arrives that is directed to an address published by Web Application Proxy, it terminates the traffic and initiates new requests to the published applications. It therefore acts as a session-level buffer between external devices and published applications. That is, when users access published applications, they do not directly access the application, instead, they access the application through Web Application Proxy.

Any other traffic that arrives at Web Application Proxy is dropped and not forwarded to the published applications. This includes any illegal HTTP or HTTPS requests that might be used as part of denial of service attacks, zero day attacks, SSL attacks, and so on.

Any authenticated request that arrives at Web Application Proxy containing an authentication token from AD FS will be inspected to make sure that the token received was intended for the client sending the token. This is done by checking that the device (through the Workplace Join certificate) corresponds to the claim within the token that identified the device when authenticated to AD FS.

Authentication and Authorization

To protect access to applications in your organization, it is recommended to allow access only to authenticated and authorized users. When you publish applications through Web Application Proxy, this is achieved through the use of AD FS, which provides authentication and enforces authorization for the published applications.

Web Application Proxy also allows pass-through preauthentication, which enables you to publish applications that do not require preauthentication or whose clients do not support the available authentication capabilities.

Authenticating Users and Devices

When you publish applications through Web Application Proxy, the process by which users and devices are authenticated before they gain access to applications is known as preauthentication. Web Application Proxy supports two forms of preauthentication:

AD FS preauthentication—When using AD FS for preauthentication, the user is required to authenticate to the AD FS server before Web Application Proxy redirects the user to the published web application. This ensures that all traffic to your published web applications is authenticated.

Pass-through preauthentication—Users are not required to enter credentials before they connect to published web applications.

Pass-through preauthentication has no impact on whether an application requires users to provide credentials to the application. That is, an application configured with pass-through preauthentication does not require users to enter credentials to get into the corporate network, but may require users to enter credentials to view the application content.

To easily access applications published by Web Application Proxy, and to use AD FS preauthentication end users should use one of the following clients:

Any client that supports HTTP redirects; for example, a web browser. Web Application Proxy performs the appropriate action on the incoming request to redirect the user to an authentication address and back to the original web address, this time with the authentication proof.

Rich clients that use HTTP basic, for example, Exchange ActiveSync.

Any client that uses MSOFBA; for example, Word, Excel, or PowerPoint. In this case, a user attempts to access a document from their Recent Documents list that is stored on a server within the corporate network.

Windows Store apps and RESTful applications with clients that use the Web Authentication Broker for authentication. A user can open an app on their device which obtains a token from AD FS via the Web Authentication Broker, and includes that token in the HTTP Authorization header in subsequent requests to the app.

Depending on the client used to access the published application, Web Application Proxy decides how to process the request.

Authentication Capabilities

When you use AD FS for authentication, you also benefit from all of the features that AD FS provides:

Workplace Join—This is a new feature in AD FS in Windows Server 2012 R2. It allows users to join devices to the workplace that would not normally be domain-joined; for example, personal laptops, tablets, and smartphones. When this feature is enabled, the AD FS administrator can configure all applications, or individual applications, to require devices to be registered before they can gain access to published applications. For more information, see Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company Applications.

SSO—This allows users to enter credentials once and be authenticated to all supported published applications. See Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company Applications.

Multifactor authentication (MFA)—AD FS can be configured to require users to authenticate with more than one authentication scheme; for example, a one-time password or a smart card. See Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications.

Multifactor access control—Access control in AD FS is implemented with authorization claim rules that are used to issue a permit or deny claims that will determine whether a user or a group of users will be allowed to access AD FS-secured resources or not. Authorization rules can only be set on relying party trusts. All of the above features can be combined, as required, to provide stricter security for confidential applications, or ignored for less confidential applications. See Manage Risk with Conditional Access Control.

When you publish applications through Web Application Proxy you are not required to configure the AD FS authentication features mentioned above. This allows you to provide access to devices that are not able to join the workplace, or provide additional factors of authentication, such as kiosks.

Web Application Proxy Technical Overview

When you decide to use Web Application Proxy in your organization, we recommend that you deploy your Web Application Proxy servers behind a frontend firewall to separate it from the Internet, or between two firewalls; a frontend firewall to separate it from the Internet, and a backend firewall to separate it from the corporate network. In this topology, Web Application Proxy provides a protection layer against malicious users that may be coming from the Internet. No other servers are required to be located in this perimeter network; that is, your AD FS servers are located in the corporate network and can only be reached via Web Application Proxy using its built-in AD FS proxy functionality.

The following diagram shows a typical topology for deploying Web Application Proxy in a perimeter network between two firewalls.

Web Application Proxy Configuration Storage

The Web Application Proxy configuration is stored on the AD FS servers in your organization; therefore, Web Application Proxy servers require connectivity to the AD FS servers. In addition, after configuring the first Web Application Proxy server, you can install additional Web Application Proxy servers to create a cluster deployment. When you install the role service on the new server in the cluster, the configuration is automatically transferred to the new server after completing the Web Application Proxy Configuration Wizard.

Since Web Application Proxy stores its configuration on the AD FS servers it has no locally stored configuration information.

AD FS Proxy Functionality

The Web Application Proxy role service is also an AD FS proxy. That is, Web Application Proxy listens to all of the end-points that AD FS listens to. Web Application Proxy also forwards any requests from the Internet to AD FS and responses from AD FS to the Internet. Note that the Web Application Proxy role service is a replacement for the AD FS proxy role.

Creating a proxy in your organization for your Federation Service adds additional security layers to your AD FS deployment. Consider deploying Web Application Proxy in your organization’s perimeter network when you want to:

Prevent external client computers from directly accessing your AD FS servers. By deploying a Web Application Proxy server in your perimeter network, you effectively isolate your AD FS servers. Web Application Proxy servers do not have access to the private keys that are used to produce tokens.

Provide a convenient way to differentiate the sign-in experience for users who are coming from the Internet as opposed to users who are coming from your corporate network using Integrated Windows authentication.

Managing Web Application Proxy

Web Application Proxy uses a number of tools and features provided by Windows Server 2012 R2 to enable you to easily install, deploy, and manage it in your corporate deployments.

Web Application Proxy is a role service in Windows Server 2012 R2. This allows you to easily install Web Application Proxy in your deployment using Server Manager or Windows PowerShell.

Web Application Proxy is integrated into the Remote Access Management console, allowing you to manage your Web Application Proxy servers and other Remote Access technologies, such as DirectAccess and VPN from the same Remote Access Management console.

Web Application Proxy provides full functionality through a set of Windows PowerShell commands and a Windows Management Instrumentation (WMI) API.

To aid troubleshooting, Web Application Proxy:

Writes events to the Windows Event log.

Exposes a number of performance counters.

Has a dedicated Best Practices Analyzer (BPA).

Interoperability with Other Remote Access Products

Web Application Proxy is a role service of the Remote Access role in Windows Server 2012 R2. You can install Web Application Proxy side-by-side with Remote Access in the following scenarios:

Web Application Proxy

Single server deployment

Single server deployment

Single server deployment

Multiple server deployment

Not supported on the same server

Not supported on the same server

Multiple server deployment

Multiple server deployment

Multiple server deployment

Multiple server deployment2

1—In a pre-existing DirectAccess cluster deployment, you can install Web Application Proxy only using Windows PowerShell. 2—In a pre-existing multiple server Web Application Proxy deployment, you can install DirectAccess only using Windows PowerShell.

Web Application Proxy provides application publishing capabilities, similar to Forefront Unified Access Gateway (UAG). However, Web Application Proxy interacts with other servers and services to provide a more streamlined deployment. This helps you to concentrate on configuring only the necessary parts of your deployment. It is recommended that for any new deployments where you require application publishing capabilities for the scenarios described above, you should use Web Application Proxy.

Источник