Planning to Publish Applications Using Web Application Proxy

 

Applies To: Windows Server 2012 R2

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.

This section describes planning steps that can be taken when you use Web Application Proxy – a Remote Access role service - to provide reverse proxy functionality for corporate web applications and services. When you use Web Application Proxy with Active Directory Federation Services (AD FS), you can manage the risk of exposing your applications to the Internet by configuring features provided by AD FS, including: Workplace Join, multifactor authentication (MFA), and multifactor access control.

Web Application Proxy also functions as an AD FS proxy.

The following diagram shows the topology used in this scenario for Web Application Proxy to publish Microsoft applications and other line-of-business (LOB) applications.

Providing Access to Applications and Services

This scenario demonstrates how to plan and deploy Web Application Proxy in your organization 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. 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. 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.

Roles and Features Included in this Scenario

The following table lists the roles and features that are part of this scenario and describes how they support it.

Role/feature	How it supports this scenario
Active Directory Domain Services	Active Directory® Domain Services is required as a prerequisite before you can deploy AD FS. It is also required for Web Application Proxy deployments that use Kerberos constrained delegation.
Active Directory Federation Services	AD FS is required to provide authentication and authorization services to Web Application Proxy and to store the Web Application Proxy configuration.

Hardware requirements

Hardware requirements for this scenario include the following:

• A computer that meets the hardware requirements for Windows Server 2012 R2 running one of the following server editions: Essentials, Standard, or Datacenter.

• The server must have at least one network adapter installed, enabled, and connected to the internal network either directly, or through a firewall or NAT device. When two adapters are used, there should be one adapter connected to the internal corporate network, and one connected to the external network (Internet, or private network).

Software requirements

Software requirements for this scenario include the following:

• If the Web Application Proxy server is located behind an edge firewall or NAT device, the device must be configured to allow traffic to and from the Web Application Proxy server.

• The person deploying Web Application Proxy on the server requires local administrator permissions on the server. In addition, when you connect the Web Application Proxy server to the AD FS server, you require the credentials of the local administrator on the AD FS servers.

• You must deploy AD FS on a server running Windows Server 2012 R2 in your organization before you can deploy Web Application Proxy.

• If you want to remotely manage Web Application Proxy servers, you must enable remote PowerShell management on the Web Application Proxy servers. See Running Remote Commands.

Plan Network Location

Web Application Proxy can be deployed in several topologies. For example, you can deploy Web Application Proxy behind a frontend firewall to separate it from the Internet, or between two firewalls; a frontend firewall to separate it from the Internet, a backend firewall to separate it from the corporate network. In both topologies, Web Application Proxy provides a protection layer against malicious HTTP requests that originate from the Internet through the following features:

• Preauthentication—Make sure that only authenticated traffic can get into the corporate network.

• Network Isolation—Incoming web traffic cannot directly access backend servers.

• Selective Publishing—Only specific applications and paths within these applications are accessible.

• DDoS Protection—Incoming traffic arrives at Web Application Proxy before entering the corporate network. Because Web Application Proxy acts as a buffer, many DDoS attacks can be prevented from reaching the backend servers.

Plan Firewalls

Deploying Web Application Proxy behind a firewall adds network level protection and reduces the attack surface of the Web Application Proxy servers. If the Web Application Proxy server is located in front of a firewall that separates it from the corporate network, you must make sure that the firewall does not block traffic to URLs configured for the backend servers. This could be over HTTP or HTTPS and on any specified port. Note that if you deploy Web Application Proxy on a domain-joined server, it must have connectivity to the domain controller, see 1.3. Plan Active Directory.

All firewall servers must be configured to allow HTTPS traffic because the firewall servers must publish Web Application Proxy using port 443 so that Web Application Proxy in the perimeter network can access the federation server in the corporate network. Port 443 is also required for device registration using Workplace Join.

Note

All federation server communications to and from client devices also occur over HTTPS.

In the federated world of AD FS, client requests are typically made to a specific URL, for example, a federation server identifier URL such as https://fs.fabrikam.com. Because these client requests originate from the Internet, the Internet-facing firewall server must be configured to publish the federation server identifier URL for each Web Application Proxy server that is deployed in the perimeter network.

If you want to use client certificate authentication, you must also configure the firewall to allow traffic on port 49443.

Plan DNS

DNS planning requirements include the following:

• Web Application Proxy requires internal name resolution to resolve the names of backend servers, and of infrastructure servers such as the AD FS server.

• When publishing web applications via Web Application Proxy, every web application you publish requires an external URL. For clients to reach these web applications, a public DNS server must be able to resolve each external URL that you configure. Note that the external URL must resolve to the external IP address of the Web Application Proxy server, or the external IP address of a firewall or load-balancer placed in front of the Web Application Proxy server.

Plan Load Balancing

Web Application Proxy does not include integrated load-balancing functionality. If you plan to deploy multiple Web Application Proxy servers, you should consider deploying a load-balancer to ensure that the external traffic is distributed evenly between Web Application Proxy servers. You can use any hardware or software load-balancer that supports HTTP and HTTPS, including Windows Network Load Balancing.

You can also configure a load-balancer for published web applications. That is, you can deploy a load-balancer between the Web Application Proxy servers and the published web application. You can use any hardware or software load-balancer that supports HTTP and HTTPS, including Windows Network Load Balancing.

Visual Basic Note: A cluster must be either completely domain joined or not domain joined.

Plan Active Directory

Web Application Proxy can be deployed without joining the server to an AD DS domain or by joining the Web Application Proxy server to a standalone domain in a perimeter network.

You can deploy Web Application Proxy with a read-only domain controller. However, if you want to deploy Web Application Proxy and DirectAccess on the same server, you cannot use a read-only domain controller.

Plan Integrated Windows authentication and Kerberos constrained delegation

When publishing applications that use Integrated Windows authentication, the Web Application Proxy server uses Kerberos constrained delegation to authenticate users to the published application.

The following diagram shows the connections from Web Application Proxy to the domain controller to get the Kerberos ticket, and the connection from Web Application Proxy to the backend server to perform Integrated Windows authentication.

To use Integrated Windows authentication, the Web Application Proxy server must be joined to an AD DS domain. The following lists the domain and forest requirements for a deployment using Integrated Windows authentication with Kerberos constrained delegation.

1. Deployments where users, resources, and Web Application Proxy servers are all in the same forest are supported.

2. In deployments with multiple forests where there is a user forest, a resource forest, and an Web Application Proxy forest, the following deployments are supported:

   1. Users, resources, and Web Application Proxy servers are all in different forests.

   2. Users and Web Application Proxy servers are in the same forest, but resources are in a different forest.

   3. Resources and Web Application Proxy servers are in the same forest, but users are in a different forest.

In multi-forest deployments:

1. The user forest must trust the Web Application Proxy forest, and the Web Application Proxy forest must trust the resource forest.

2. All of the Active Directory domains in a multi-forest deployment must have at least one Windows Server® 2012 or higher domain controller. For more information, see Kerberos Constrained Delegation across Domains

Plan Active Directory Federation Services

Web Application Proxy can use AD FS for preauthentication; that is, when you configure web applications to use AD FS preauthentication, unauthenticated client requests are redirected to the AD FS server for authentication and authorization before forwarding the request to the published web application.

AD FS Requirements

When planning AD FS for Web Application Proxy deployments, the following is required:

• At least one AD FS server installed on the Windows Server 2012 R2 operating system.

Plan Preauthentication

Web Application Proxy enables you to use two forms of preauthentication:

• AD FS—When using AD FS preauthentication, you can also use Integrated Windows authentication. See Plan to Publish Applications using AD FS Preauthentication [WAP].

• Pass-through preauthentication—When using pass-through preauthentication, Web Application Proxy does not authenticate users before they are allowed to connect to published web applications. See Plan to Publish Applications using Pass-through Preauthentication [WAP].

Plan the Web Application Proxy Role Service Installation

The following table describes the supported Remote Access role service deployments.

DirectAccess	VPN	Web Application Proxy
Single server deployment	Single server deployment	Single server deployment
Multisite deployment	Multiple server deployment	Not supported on the same server
Not supported on the same server	Multiple server deployment	Multiple server deployment
Cluster deployment1	Multiple server deployment	Multiple server deployment2

Note

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.

Important

If you deploy DirectAccess and Web Application Proxy on the same server, you cannot use a read-only domain controller.

You can deploy the Web Application Proxy role service on a server that is also running the Internet Information Services (IIS) role. However, in this type of deployment, you must make sure that IIS is configured to only listen, or be bound, to URLs that are not configured as external URLs on Web Application Proxy.

Plan Multiple Servers

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

Plan Certificates

The following table describes the certificates that are required when deploying Web Application Proxy, and any other requirements when using those certificates.

Certificate purpose and location1	Certificate issuer2	Notes
Server authentication for the Web Application Proxy server. Import the certificate to the Personal Certificates store on all Web Application Proxy servers.	Public CA Enterprise CA (internal)	- For clients to be able to connect to published web applications using HTTPS, Web Application Proxy must present a certificate that is trusted by clients. Because clients are not required to be included in your PKI, this usually requires you to acquire a certificate from an external certification authority (CA). - It is not recommended to use an Enterprise CA if users are allowed to use their own devices to access published applications. - You can use single name certificates, subject alternative name (SAN) certificates, or wildcard certificates. - You may require more than one certificate to successfully publish all the required applications.
Server authentication for the federation server. Import the certificate to the Personal Certificates store on all Web Application Proxy servers.	Public CA Enterprise CA (internal)	This certificate is required for AD FS proxy functionality.   The subject of this certificate must match the Federation Service name value that is specified in the AD FS Management console. To locate this value, open the AD FS Management console, click Service, in the Actions pane, click Edit Federation Service Properties, and then find the value in the Federation Service name text box. For Workplace Join, the certificate must have the following subject alternative names (SANs):   <federation service name>.<domain> For example, adfs1.contoso.com. enterpriseregistration.<domain> For example, enterpriseregistration.contoso.com.  Note: Only one certificate is required for server authentication for the federation server.

Note

1—If any certificate that you use has certificate revocation lists (CRLs), the server with the configured certificate must be able to contact the server that distributes the CRLs; the CRL distribution point (CDP). Clients must be able to reach the CDP. The type of CRL determines what ports are used. 2—In all cases, the client must trust the issuing CA and any intermediate CAs.

Plan NTP

When using AD FS preauthentication, the time of all Web Application Proxy servers must be identical to the time of the AD FS servers so that the timestamps on claims match. The time of all Web Application Proxy servers must be identical to the time of the applications servers when using Kerberos constrained delegation. It is recommended to enable Network Time Protocol (NTP) on all Web Application Proxy and AD FS servers.

Plan for Client Certificate Preauthentication

• Plan the external servers:

  To use client certificate preauthentication, the external servers must have a certificate issued by a public certification authority (CA). For information about requesting and configuring this certificate, see the documentation for your server. All of the external servers that you use to connect to the published web application must have the same certificate.

  The certificate can be issued by any trusted certification authority, and you must be able to obtain the certificate thumbprint.

• Plan applications that work with client certificate preauthentication:

  To publish an application using client certificate preauthentication, you do not require a relying party trust for the application.

  Note

  Applications that use client certificate preauthentication cannot leverage the additional features that AD FS provides; such as, Workplace Join, multifactor authentication (MFA), and multifactor access control.

Known issues

The following are known issues when configuring Web Application Proxy:

• When the token-signing certificate is updated in the Federation Service, the public key of the certificate is not automatically updated on the Web Application Proxy servers. To resolve this issue, you must manually import the new token-signing certificate to the Web Application Proxy servers.

• When you configure the Device Registration Service on your Federation Service, you can also enable device authentication for all relying parties with the following PowerShell command:

  Set-AdfsGlobalAuthenticationPolicy –DeviceAuthenticationEnabled $true
  

  When you publish applications with Web Application Proxy, you can publish more than one application using the same host name. You can also configure each application to authenticate the certificate presented by client devices. To validate client certificates for an application, use the following PowerShell command:

  Set-WebApplicationProxyApplication -id <Published Application ID> -ClientCertificateAuthenticationBindingMode ValidateCertificate
  

  Because Web Application Proxy uses the HTTP protocol stack (http.sys), this configuration setting must be identical for all applications that use the same host name.