How to Configure Windows Server Web Application Proxy (WAP) for AD FS Pre-Authentication

The Perimeter Vulnerability

When an enterprise hosts an internal web application (such as an HR portal, a CRM, or a legacy inventory system) and wants to make it accessible to employees working from home, the traditional solution is a VPN. If a VPN is too cumbersome, some administrators simply punch a hole in the corporate firewall and expose the internal web server directly to the public internet on port 443.

Exposing an internal IIS server directly to the internet is a catastrophic security risk. If an attacker discovers a zero-day vulnerability in the web application’s code, they compromise the IIS server. Because that server is joined to the internal Active Directory domain, the attacker now has a foothold inside the corporate network and can begin moving laterally to steal domain controller credentials.

To mathematically isolate internal applications while still allowing external access, Microsoft developed the Web Application Proxy (WAP). WAP acts as a reverse proxy deployed in the Demilitarized Zone (DMZ). It completely severs the direct connection between the internet and the internal network. More importantly, when integrated with Active Directory Federation Services (AD FS), WAP enforces Pre-Authentication. An attacker cannot even send a single HTTP packet to the internal HR portal until they have successfully authenticated with AD FS and satisfied Multi-Factor Authentication (MFA) at the DMZ edge.

Step 1: The DMZ Architecture

The WAP architecture requires strict network segmentation.

• The WAP Server: This Windows Server is placed in the DMZ. It must have a public IP address (or NAT) and a public DNS record (e.g., hr.corp.com). Crucially, the WAP server must NEVER be joined to the internal Active Directory domain. It remains a standalone workgroup server to prevent credential theft if it is compromised.
• The AD FS Server: This server sits deep inside the internal network. It handles the actual cryptographic authentication.
• The Firewall Rules: The external firewall only allows port 443 (HTTPS) to hit the WAP server. The internal firewall only allows the WAP server to talk to the AD FS server on port 443, and to the specific internal web application (e.g., the HR portal) on port 443. The WAP server cannot ping or access anything else on the internal network.

Step 2: Establishing the Cryptographic Trust

Because the WAP server is not joined to the domain, it has no inherent trust relationship with the internal AD FS server. You must build a manual cryptographic bridge.

Log into the WAP server in the DMZ. Install the Remote Access role:

Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools

You must import the exact same SSL certificate used by your internal AD FS server (e.g., sts.corp.com) into the Local Machine certificate store of the WAP server. The WAP server must also have a local HOSTS file entry pointing sts.corp.com to the internal IP address of the AD FS server.

Now, run the configuration wizard via PowerShell to bind the WAP server to AD FS. You must provide the credentials of an internal Domain Admin for this one-time binding process.

Install-WebApplicationProxy -CertificateThumbprint "A1B2C3D4E5..." -FederationServiceName "sts.corp.com"

Step 3: Creating the Relying Party Trust (AD FS)

Before WAP can publish an application, the internal AD FS server must know how to authenticate users for it.

Log into the internal AD FS server. Open the AD FS Management Console.

1. Right-click Relying Party Trusts and select Add Relying Party Trust.
2. Select Non-claims aware (This is required if you are publishing a legacy application that uses standard Windows Integrated Authentication (Kerberos) instead of modern SAML/OAuth).
3. Name it “Internal HR Portal”.
4. Configure an Issuance Authorization Rule to permit all users (or restrict it to a specific AD group).

Step 4: Publishing the Application (WAP)

Now, return to the WAP server in the DMZ. You must instruct WAP to intercept internet traffic and route it through AD FS.

Open the Remote Access Management Console.

1. Click Publish.
2. Select Active Directory Federation Services (AD FS) for Pre-Authentication.
3. Select the “Internal HR Portal” Relying Party Trust you created in Step 3.
4. Name: HR Portal
5. External URL: https://hr.corp.com/ (This is what the employee types into their home browser). Select the matching public SSL certificate.
6. Backend Server URL: https://internal-hr-server.corp.local/ (This is the hidden, internal URL that WAP will route the traffic to).
7. SPN (Service Principal Name): Enter the HTTP SPN of the internal server (e.g., HTTP/internal-hr-server.corp.local). This allows WAP to perform Kerberos Constrained Delegation (KCD), transforming the external AD FS token into an internal Kerberos ticket.

Step 5: The Execution Flow (Zero-Trust in Action)

The architecture is now active. Here is the exact mathematical sequence of events when a remote employee attempts to access the HR portal:

1. The employee types https://hr.corp.com into their home browser.
2. The browser hits the WAP server in the DMZ.
3. The WAP server instantly intercepts the connection. It sees that Pre-Authentication is required. It forcefully bounces the user’s browser to the AD FS login page (https://sts.corp.com).
4. The user types their AD username, password, and Microsoft Authenticator MFA code.
5. AD FS mathematically validates the credentials and issues a cryptographically signed cookie (an Edge Access Token) to the browser.
6. The browser redirects back to the WAP server, presenting the signed token.
7. The WAP server validates the signature. Because the token is valid, WAP finally opens a proxy connection through the internal firewall, performs protocol transition to Kerberos, logs the user into the HR portal invisibly, and streams the HTML back to the external browser.

If an attacker runs an automated vulnerability scanner against https://hr.corp.com, every single malicious HTTP payload is instantly rejected at the DMZ. The attacker never touches the internal HR server, because they do not possess a mathematically signed AD FS token.

Conclusion

Exposing internal IIS applications directly to the internet is a guaranteed pathway to corporate compromise. By deploying the Windows Server Web Application Proxy (WAP) in the DMZ, security architects construct a mathematically impenetrable reverse-proxy barrier. The enforcement of AD FS Pre-Authentication ensures that every single inbound request is cryptographically validated and MFA-challenged at the absolute edge of the network, transforming legacy internal web servers into Zero-Trust, internet-ready applications.