Step 1: Plan the Web Application Proxy Infrastructure
Updated: August 26, 2013
Applies To: Windows Server 2012 R2
The first step of planning for a Web Application Proxy deployment is to perform planning for the infrastructure required for the deployment. This topic describes the infrastructure planning steps.
| Task | Description |
|---|---|
1.1. Plan Network Location |
Decide where to place the Web Application Proxy server and prepare your firewalls for an Web Application Proxy deployment. |
1.2. Plan DNS |
Plan DNS settings for the Web Application Proxy server, infrastructure servers, and application servers. |
1.3. Plan Load Balancing |
Decide what type of load-balancing you require for the Web Application Proxy servers and the web application servers. |
1.4. Plan Active Directory |
Plan your Active Directory requirements, in particular the requirements if you plan to publish applications that use Integrated Windows authentication. |
1.5. Plan Active Directory Federation Services |
Plan your Active Directory Federation Services (AD FS) requirements. |
1.6. Plan Preauthentication |
Decide what type of preauthentication you will use when publishing applications through Web Application Proxy. |
1.1. 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.4. 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.
1.2. 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.
1.3. 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.
.jpeg "note") Visual Basic Note |
|---|
| A cluster must be either completely domain joined or not domain joined. |
1.4. 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.
.png "Web Application Proxy Integrated Windows auth")
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.
Deployments where users, resources, and Web Application Proxy servers are all in the same forest are supported.
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:
Users, resources, and Web Application Proxy servers are all in different forests.
Users and Web Application Proxy servers are in the same forest, but resources are in a different forest.
Resources and Web Application Proxy servers are in the same forest, but users are in a different forest.
In multi-forest deployments:
The user forest must trust the Web Application Proxy forest, and the Web Application Proxy forest must trust the resource forest.
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
1.5. 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.
1.6. 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 Step 3: Plan to Publish Applications using AD FS Preauthentication.
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 Step 5: Plan to Publish Applications using Pass-through Preauthentication.