How to Install and Configure Web Application Proxy on Windows Server 2025

How to Install and Configure Web Application Proxy on Windows Server 2025

Web Application Proxy (WAP) is a Remote Access role service on Windows Server 2025 that acts as a reverse proxy, enabling you to publish internal applications securely to external users without exposing those applications directly to the internet. WAP integrates tightly with Active Directory Federation Services (AD FS) to provide pre-authentication — users authenticate against AD FS before a single packet reaches the internal application. This guide covers installing WAP, connecting it to AD FS, publishing applications with both pass-through and claims-aware pre-authentication, publishing Remote Desktop Gateway, configuring firewall rules, and building a highly available deployment.

Prerequisites

• A working AD FS farm on Windows Server 2025 (or 2022 in mixed mode) — WAP requires AD FS 4.0 or later
• A separate Windows Server 2025 machine for WAP (WAP must NOT be a domain member — it sits in the DMZ)
• SSL certificate covering the AD FS service name and all published application hostnames (a wildcard or SAN certificate is practical)
• The certificate installed in the Local Machine personal store on both the AD FS server and the WAP server
• DNS records resolving AD FS service name and application FQDNs to the WAP server’s external IP from the internet
• Internal firewall allowing WAP to reach AD FS on TCP 443 and TCP 49443
• Administrator credentials on both the AD FS server and the WAP server

Step 1: Install the Web Application Proxy Role Service

On the designated WAP server (in the DMZ), install the role using PowerShell. Do not join the WAP server to the domain — it communicates with AD FS over SSL only:

# Install Web Application Proxy role service
Install-WindowsFeature -Name Web-Application-Proxy -IncludeManagementTools

# Verify installation
Get-WindowsFeature -Name Web-Application-Proxy

The cmdlet installs the WAP role and its management tools, including the WebApplicationProxy PowerShell module and a snap-in for Remote Access Management Console.

Step 2: Configure WAP — Connect to AD FS

The Install-WebApplicationProxy cmdlet performs the initial WAP configuration. You need the AD FS service federation metadata URL, the thumbprint of the SSL certificate bound to AD FS, and AD FS admin credentials:

# Get the certificate thumbprint from the WAP server's cert store
Get-ChildItem -Path Cert:LocalMachineMy | Where-Object { $_.Subject -like "*adfs.contoso.com*" } |
    Select-Object Subject, Thumbprint

# Connect WAP to the AD FS farm
# Replace values with your environment's specifics
$ADFSUrl       = "https://adfs.contoso.com/federationmetadata/2007-06/federationmetadata.xml"
$CertThumb     = "A1B2C3D4E5F6A1B2C3D4E5F6A1B2C3D4E5F6A1B2"
$ADFSCred      = Get-Credential "CONTOSOADFSServiceAccount"

Install-WebApplicationProxy `
    -CertificateThumbprint $CertThumb `
    -FederationServiceName "adfs.contoso.com" `
    -FederationServiceTrustCredential $ADFSCred

# Verify WAP is operational
Get-WebApplicationProxyConfiguration

A successful run returns the proxy configuration including the AD FS URL, certificate details, and a connected proxy status. If the command fails with a trust error, verify that the AD FS SSL certificate is trusted on the WAP server (install the root CA certificate if using an internal PKI).

Step 3: Publish a Pass-Through (Non-Claims-Aware) Application

Pass-through publishing makes WAP forward requests to the backend without pre-authenticating users against AD FS. This is suitable for applications with their own authentication (e.g., an intranet portal, OWA, or a third-party app):

# Publish an internal web application using pass-through
# WAP listens on the ExternalUrl and forwards to BackendServerUrl

Add-WebApplicationProxyApplication `
    -Name "Contoso Intranet Portal" `
    -ExternalPreAuthentication PassThrough `
    -ExternalUrl "https://portal.contoso.com/" `
    -BackendServerUrl "http://intranet.corp.contoso.com/" `
    -ExternalCertificateThumbprint $CertThumb

# List published applications
Get-WebApplicationProxyApplication | Select-Object Name, ExternalUrl, BackendServerUrl, ExternalPreAuthentication

WAP will terminate the external TLS connection, then optionally re-encrypt to the backend. For pass-through to an HTTP backend over the internal network, this is a common pattern when the internal network is trusted.

Step 4: Publish a Claims-Aware Application (AD FS Pre-Authentication)

For claims-aware applications — those configured as Relying Party Trusts in AD FS — WAP enforces authentication before the request reaches the backend. Users authenticate to AD FS and receive a security token, which WAP validates before proxying:

# First, ensure the application's Relying Party Trust exists in AD FS
# Then publish with ADFSforRichClients or ADFS pre-authentication

$AppCertThumb  = "B2C3D4E5F6A1B2C3D4E5F6A1B2C3D4E5F6A1B2C3"
$BackendUrl    = "https://crm.corp.contoso.com/"
$ExternalUrl   = "https://crm.contoso.com/"

Add-WebApplicationProxyApplication `
    -Name "Contoso CRM" `
    -ExternalPreAuthentication ADFS `
    -ADFSRelyingPartyName "Contoso CRM App" `
    -ExternalUrl $ExternalUrl `
    -BackendServerUrl $BackendUrl `
    -ExternalCertificateThumbprint $AppCertThumb `
    -BackendServerAuthenticationSPN "http/crm.corp.contoso.com"

The -BackendServerAuthenticationSPN parameter is required when using Kerberos Constrained Delegation (KCD) for the backend leg — WAP will impersonate the authenticated user to the backend server using Kerberos.

Step 5: Publish Remote Desktop Gateway

WAP can pre-authenticate and proxy Remote Desktop Gateway connections, allowing external users to access internal RDS resources through AD FS authentication:

# WAP for RD Gateway requires specific port and backend configuration
# RD Gateway uses HTTPS (443) and the RPC-over-HTTP endpoint

Add-WebApplicationProxyApplication `
    -Name "RD Gateway" `
    -ExternalPreAuthentication PassThrough `
    -ExternalUrl "https://rdg.contoso.com/RDWeb/" `
    -BackendServerUrl "https://rdgateway.corp.contoso.com/RDWeb/" `
    -ExternalCertificateThumbprint $CertThumb `
    -DisableTranslateUrlInRequestHeaders $false

# For the RPC endpoint (required for RemoteApp and full RDP)
Add-WebApplicationProxyApplication `
    -Name "RD Gateway RPC" `
    -ExternalPreAuthentication PassThrough `
    -ExternalUrl "https://rdg.contoso.com/rpc/" `
    -BackendServerUrl "https://rdgateway.corp.contoso.com/rpc/" `
    -ExternalCertificateThumbprint $CertThumb

Step 6: Configure Windows Firewall Rules

WAP sits in the DMZ. The following firewall rules are required on the WAP server and the perimeter firewall:

# Allow inbound HTTPS from internet (external clients)
New-NetFirewallRule `
    -Name "WAP-Inbound-HTTPS" `
    -DisplayName "Web Application Proxy - HTTPS (443)" `
    -Protocol TCP `
    -LocalPort 443 `
    -Direction Inbound `
    -Action Allow `
    -Profile Any

# Allow inbound on 49443 (AD FS proxy port for certificate authentication)
New-NetFirewallRule `
    -Name "WAP-Inbound-ADFS-Proxy" `
    -DisplayName "Web Application Proxy - AD FS Proxy Port (49443)" `
    -Protocol TCP `
    -LocalPort 49443 `
    -Direction Inbound `
    -Action Allow `
    -Profile Any

# Verify WAP can reach AD FS on 443 and 49443 from the DMZ
Test-NetConnection -ComputerName adfs.contoso.com -Port 443
Test-NetConnection -ComputerName adfs.contoso.com -Port 49443

On the internal firewall (between DMZ and corporate LAN), allow outbound TCP 443 and TCP 49443 from the WAP server IP to the AD FS server IP, plus TCP 443 to each backend server URL you publish.

Step 7: High Availability WAP Deployment

For production environments, deploy at least two WAP servers behind an external load balancer. WAP itself is stateless — all session state is held in AD FS or in cookies, so load balancing requires no sticky sessions for most scenarios:

# After configuring a second WAP server identically, verify both are in sync
# Run this on each WAP node to confirm they reference the same AD FS farm

Get-WebApplicationProxyConfiguration | Select-Object ADFSSignCertificateThumbprint, ADFSUrl

# List all published applications from any WAP node (they share config via AD FS)
Get-WebApplicationProxyApplication | Format-Table Name, ExternalUrl, ExternalPreAuthentication -AutoSize

# Monitor WAP health endpoint (AD FS proxy health)
Invoke-WebRequest -Uri "https://adfs.contoso.com/adfs/probe" -UseBasicParsing | Select-Object StatusCode

Configure your external load balancer (Azure Load Balancer, F5, or Windows NLB) to health-check the AD FS proxy probe endpoint and distribute traffic across WAP nodes. Use the same SSL certificate on all WAP nodes.

Web Application Proxy on Windows Server 2025 provides a robust, AD-integrated reverse proxy solution without requiring third-party software. By pre-authenticating users through AD FS, WAP ensures that unauthenticated requests never touch your internal application servers, dramatically reducing the attack surface of your internet-facing services. As your organization’s publishing requirements grow, WAP scales horizontally with additional DMZ nodes, and its tight integration with the Windows PKI and certificate infrastructure makes SSL management straightforward through familiar Windows tooling.