How to Configure Windows Server 2022 Security Settings

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

Web Application Proxy (WAP) is a remote access role service in Windows Server 2022 that functions as a reverse proxy, allowing external clients to securely access internal web applications without a traditional VPN. WAP integrates deeply with Active Directory Federation Services (AD FS) to support pre-authentication, meaning users must authenticate before their request is forwarded to the backend application. This guide covers the full deployment of WAP from installation through application publishing, Kerberos delegation, health monitoring, and troubleshooting.

Web Application Proxy Role Overview

WAP is part of the Remote Access server role. It differs from a traditional reverse proxy like NGINX or ARR in two key ways. First, it supports AD FS pre-authentication, where users authenticate with the federation service before WAP forwards their request to the backend. Second, it is Active Directory-aware and can participate in claims-based identity flows.

WAP has two pre-authentication modes: pass-through, where WAP forwards requests to the backend without pre-authenticating, and AD FS, where WAP enforces federation-based authentication first. The AD FS mode is appropriate for Office-style enterprise applications, while pass-through works for applications that handle their own authentication.

WAP is typically deployed in a perimeter network (DMZ) with one NIC facing the internet and one facing the internal network where AD FS and the backend applications reside.

Prerequisites

Before installing WAP, you need a working AD FS deployment. WAP acts as an AD FS proxy, so it must be able to reach the AD FS server on port 443. You also need:

– A publicly trusted SSL certificate for the AD FS federation service name (e.g., sts.example.com)
– A certificate for each web application you plan to publish via WAP
– DNS entries for external names pointing to the WAP server’s external IP
– The WAP server should NOT be domain-joined if it is in a DMZ; it communicates with AD FS over HTTPS without domain membership

Install the AD FS role on a separate, domain-joined server first. The WAP server only needs to trust the AD FS TLS certificate. Import the AD FS certificate to the WAP server’s Trusted Root Certification Authorities store:

Import-Certificate -FilePath "C:certsadfs-root-ca.cer" -CertStoreLocation Cert:LocalMachineRoot

Installing the Web Application Proxy Role

WAP is installed from Server Manager or PowerShell as a sub-component of the Remote Access role. On the WAP server, open an elevated PowerShell window:

Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools

This installs the WAP role service and the Remote Access Management tools. You do not need to install the full Remote Access role (VPN, DirectAccess) — WAP is an independent role service. After installation, the Remote Access Management Console will be available.

Verify installation:

Get-WindowsFeature Web-Application-Proxy

Configuring Web Application Proxy

After installation, WAP must be configured using the Web Application Proxy Configuration Wizard, which connects the WAP server to AD FS. Run the wizard from the Remote Access Management Console or use PowerShell.

The configuration requires the AD FS federation service name, a local administrator credential for the AD FS server (to enroll the WAP as a trusted proxy), and the thumbprint of the certificate that WAP will use for the AD FS proxy trust.

$adfsCredential = Get-Credential -Message "Enter AD FS admin credentials"

Install-WebApplicationProxy `
    -FederationServiceTrustCredential $adfsCredential `
    -FederationServiceName "sts.example.com" `
    -CertificateThumbprint "A1B2C3D4E5F6A1B2C3D4E5F6A1B2C3D4E5F6A1B2"

If the certificate thumbprint is unknown, list certificates in the personal store:

Get-ChildItem Cert:LocalMachineMy | Select-Object Subject, Thumbprint, NotAfter

After running Install-WebApplicationProxy, the WAP service (appproxysvc) will start and establish a trust relationship with AD FS. The AD FS server will show the WAP server in its proxy list.

Publishing Applications with Pass-Through Pre-Authentication

Pass-through is the simplest publishing mode. WAP forwards all requests directly to the backend without authenticating the user. This is appropriate for applications that have their own authentication mechanism or are public-facing.

Add-WebApplicationProxyApplication `
    -Name "Intranet Portal" `
    -ExternalPreAuthentication PassThrough `
    -ExternalUrl "https://portal.example.com/" `
    -BackendServerUrl "http://intranet.corp.example.com/" `
    -ExternalCertificateThumbprint "A1B2C3D4E5F6A1B2C3D4E5F6A1B2C3D4E5F6A1B2"

In this example, requests arriving at https://portal.example.com are forwarded to http://intranet.corp.example.com. The external URL uses HTTPS (WAP terminates TLS) while the backend URL can use HTTP for internal traffic if the network is trusted.

Publishing Applications with AD FS Pre-Authentication

AD FS pre-authentication requires the user to authenticate with the federation service before their request reaches the backend. WAP redirects unauthenticated users to the AD FS login page, validates the resulting token, and only then proxies the request to the backend.

Add-WebApplicationProxyApplication `
    -Name "HR Application" `
    -ExternalPreAuthentication ADFS `
    -ADFSRelyingPartyName "HR Application RP" `
    -ExternalUrl "https://hr.example.com/" `
    -BackendServerUrl "https://hrapp.corp.example.com/" `
    -ExternalCertificateThumbprint "B2C3D4E5F6A1B2C3D4E5F6A1B2C3D4E5F6A1B2C3"

The ADFSRelyingPartyName must exactly match the relying party trust name configured in AD FS. If the relying party does not exist in AD FS, the configuration will fail. Create the relying party trust in AD FS Management before publishing the application.

Kerberos Constrained Delegation for WAP

When WAP uses AD FS pre-authentication and the backend application uses Windows Integrated Authentication (Kerberos), WAP needs to impersonate the authenticated user when forwarding the request to the backend. This requires Kerberos Constrained Delegation (KCD) to be configured for the WAP computer account in Active Directory.

On a domain controller, configure KCD so the WAP computer account can delegate to the backend application’s service principal name (SPN). For example, if the HR application runs on hrapp.corp.example.com and uses HTTP:

# Run on a domain controller
$wapComputer = Get-ADComputer -Identity "WAP01"

Set-ADComputer -Identity $wapComputer -Add @{
    "msDS-AllowedToDelegateTo" = "HTTP/hrapp.corp.example.com", "HTTP/hrapp"
}

# Set the account to use constrained delegation only (not unconstrained)
Set-ADAccountControl -Identity $wapComputer -TrustedForDelegation $false
Set-ADAccountControl -Identity $wapComputer -TrustedToAuthForDelegation $true

Then register the SPN on the backend server’s service account if it is not already present:

setspn -A HTTP/hrapp.corp.example.com DOMAINhrapp-service-account
setspn -A HTTP/hrapp DOMAINhrapp-service-account

WAP with Claims-Based Applications

For applications that use WS-Federation or SAML claims (such as SharePoint, custom ASP.NET apps using Windows Identity Foundation, or Office 365 hybrid scenarios), the authentication flow goes through AD FS automatically when WAP is in AD FS pre-authentication mode. The application receives claims in the token passed by AD FS and does not need to prompt the user for credentials.

The relying party trust in AD FS must be configured to issue the correct claims for the application. For example, a relying party trust for an ASP.NET application might issue email, UPN, and group claims. These claims are included in the SAML token or the WS-Federation security token and passed to the application in the HTTP header or as a cookie after WAP forwards the request.

WAP SSL Certificate Requirements

Each published application that uses HTTPS externally requires an SSL certificate bound to the external URL. Wildcard certificates (e.g., *.example.com) are commonly used to cover multiple published applications under a single domain. Subject Alternative Name (SAN) certificates can also cover multiple specific FQDNs.

Import the certificate for each published application on the WAP server:

Import-PfxCertificate -FilePath "C:certsstar-example-com.pfx" `
    -CertStoreLocation "Cert:LocalMachineMy" `
    -Password (ConvertTo-SecureString "PfxPassword" -AsPlainText -Force)

Then reference the certificate thumbprint when adding the application via Add-WebApplicationProxyApplication. List all certificates to find the thumbprint:

Get-ChildItem Cert:LocalMachineMy | Format-List Subject, Thumbprint, NotAfter

WAP Health Monitoring

WAP exposes operational data through the Remote Access Management Console and through Windows event logs. The primary event logs for WAP are located at Applications and Services Logs > Microsoft > Windows > WebApplicationProxy.

To check the operational status of WAP services:

Get-RemoteAccessHealth

To list all published applications and their current status:

Get-WebApplicationProxyApplication | Select-Object Name, ExternalUrl, BackendServerUrl, ExternalPreAuthentication

For health of the AD FS proxy trust, check the proxy configuration state:

Get-WebApplicationProxyConfiguration

This shows the federation service name and the certificate thumbprint used for the proxy trust. If the trust certificate is near expiration, renew it before it expires to avoid service disruption.

Troubleshooting Web Application Proxy

The most common issues with WAP are certificate problems, firewall blocks, and AD FS connectivity failures. Start diagnostics by checking the WAP event log for errors:

Get-WinEvent -LogName "Microsoft-Windows-WebApplicationProxy/Admin" -MaxEvents 50 | Format-List TimeCreated, Message

Test connectivity from the WAP server to the AD FS service:

Test-NetConnection -ComputerName sts.example.com -Port 443

Test connectivity from the WAP server to the backend application:

Test-NetConnection -ComputerName hrapp.corp.example.com -Port 443

If WAP returns a 503 Service Unavailable to external clients, the backend server is unreachable or returned an error. Check that the BackendServerUrl is correct and that the WAP server’s IP is allowed through any internal firewalls to reach the backend server.

For 401 Unauthorized errors on AD FS pre-authenticated applications, verify the relying party trust is correctly configured in AD FS and that the ADFSRelyingPartyName in the WAP application matches exactly. Also check that the user’s account has not been restricted in AD FS issuance authorization rules.

To update the backend URL for an existing published application:

Set-WebApplicationProxyApplication -Name "HR Application" -BackendServerUrl "https://hrapp2.corp.example.com/"

Web Application Proxy on Windows Server 2022 provides a tightly integrated way to securely expose internal applications without a full VPN infrastructure. When combined with AD FS pre-authentication and properly configured Kerberos delegation, it delivers single sign-on to internal applications for remote users while keeping the backend servers isolated from direct internet exposure.