1. The Real‑World Problem

Right now your ADFS‑federated OWA only works inside the corporate network. Employees at home, on the road, or using mobile devices must connect via VPN just to check email. That’s painful.

Microsoft’s answer is the Web Application Proxy (WAP) – a reverse proxy that sits in your DMZ and safely publishes internal web applications. It integrates directly with ADFS to perform pre‑authentication before traffic ever hits your internal servers. Add Multi‑Factor Authentication (MFA) and you’ve got a robust, secure extranet solution.

In this lab we’ll build a WAP server, publish Exchange OWA, and enforce MFA for external users.

2. Pre‑Lab Checklist

• ✅ DC01, ADFS01, EXCH01 from previous labs fully working
• ✅ ADFS farm running with Exchange OWA as a relying party (Part 4)
• ✅ A new VM for WAP01 (non‑domain‑joined, simulating DMZ)
• ✅ WAP01 can reach ADFS01 on port 443 (firewall allow)
• ✅ A public‑facing DNS name for OWA (e.g., mail.corp.lab) – in lab we’ll use the same internal name but point external clients to WAP

3. Step 1 – Deploy the Web Application Proxy Server (WAP01)

1. Create a new Windows Server 2022 VM named WAP01.
2. Do not join it to the domain. It should remain in a workgroup.
3. Set its IP to 192.168.10.30 (or a separate DMZ range if you prefer).
4. Ensure it can resolve sts.corp.lab – either use a HOSTS file entry pointing to ADFS01’s IP, or configure DNS to use DC01.
5. Install the Remote Access role with Web Application Proxy:

Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools

4. Step 2 – Trust a Certificate for the WAP-ADFS Connection

WAP will connect to ADFS over HTTPS using the sts.corp.lab certificate. Since our lab uses an internal CA, we need to make sure WAP trusts it.

1. On ADFS01, export the root CA certificate (not the token‑signing cert). Open certlm.msc, go to Trusted Root Certification Authorities → Certificates, find CorpLab-Root-CA, and export it as a Base‑64 .CER file.
2. Copy it to WAP01 and import it into the Trusted Root Certification Authorities store (Local Machine).

Now WAP01 will trust the SSL certificate presented by ADFS01.

5. Step 3 – Configure Web Application Proxy to Connect to ADFS

On WAP01, open the Remote Access Management console and run the Web Application Proxy Configuration Wizard.

1. Provide the ADFS server name: sts.corp.lab.
2. Enter credentials that have local admin rights on ADFS01 (e.g., CORP\Administrator). This is needed only once to establish a trust between WAP and ADFS.
3. The wizard will retrieve federation metadata and create the proxy trust.

Once completed, you’ll see the proxy trust under AD FS Management → Application Proxy on ADFS01.

6. Step 4 – Publish Exchange OWA via WAP

Still on WAP01, in the Remote Access Management console, click Publish to add a new application.

1. Name: Exchange OWA (External)
2. Pre‑authentication: Active Directory Federation Services (AD FS)
3. Relying Party: Select Exchange OWA (the trust we created in Part 4)
4. External URL: https://mail.corp.lab/owa/ (this is what internet users will type)
5. Backend URL: https://mail.corp.lab/owa/ (the actual internal OWA server)
6. Leave the certificate settings as “Use the same certificate as AD FS” (or bind a separate public certificate if you have one – for lab, the same self‑signed CA cert works).

Complete the wizard. The application will show as Published.

7. Step 5 – Test External Access (Simulated)

Now simulate an external user by pointing a client machine’s DNS (or HOSTS file) to resolve mail.corp.lab to WAP01’s IP address (192.168.10.30).

1. From that client, browse to https://mail.corp.lab/owa.
2. The WAP intercepts the request, sees no session, and redirects to ADFS for authentication.
3. You should see the ADFS sign‑in page (even though you’re “outside”).
4. After successful login, you’re redirected back to OWA and your mailbox loads.

Congratulations – you’ve just published Exchange OWA to the internet securely, without opening any firewall port directly to your internal Exchange server!

8. Step 6 – Enforce Multi‑Factor Authentication (MFA) for External Users

External access demands stronger security. We’ll use ADFS’s built‑in MFA capabilities to require a second factor for all requests coming through the WAP.

8.1 Create an Access Control Policy in ADFS

1. On ADFS01, open AD FS Management → Access Control Policies.
2. Right‑click → Add Access Control Policy.
3. Name it Require MFA for Extranet.
4. In the If section, add a condition: Network location → is not → Intranet. (ADFS detects intranet vs. extranet based on the IP of the incoming request – WAP traffic appears as extranet.)
5. In the Then section, check Require multi‑factor authentication.

8.2 Apply the Policy to the Exchange OWA Relying Party

1. Right‑click the Exchange OWA relying party trust → Properties → Access Control Policy tab.
2. Select the new policy Require MFA for Extranet.

8.3 Configure MFA (Built‑in Certificate Authentication)

For a quick lab, we’ll use ADFS’s certificate‑based MFA (client certificates). In production you’d integrate Azure MFA or a third‑party provider. Here we’ll enable it simply:

Set-AdfsGlobalAuthenticationPolicy -MultiFactorAuthentication CertificateAuthentication

Now test: from your “external” client, access OWA again. After entering your password, you’ll be prompted for a client certificate (or another MFA method if you’ve configured alternatives). Without it, access is denied.

9. How It All Fits Together

The Web Application Proxy acts as a reverse proxy that understands ADFS authentication. When an external user tries to reach OWA:

1. The request hits WAP, which checks if the user has a valid ADFS session cookie.
2. If not, WAP redirects the browser to ADFS for authentication.
3. ADFS performs the login (and, thanks to the access control policy, enforces MFA because the request is marked as extranet).
4. After successful authentication, ADFS issues a token that the browser sends back to WAP.
5. WAP validates the token, then forwards the original request to the internal Exchange server, inserting the appropriate identity headers.

This way, Exchange never sees the user’s password—it just receives a verified identity claim.

10. Troubleshooting

• WAP configuration fails? – Ensure WAP can resolve sts.corp.lab and that the root CA cert is trusted. Also check that the ADFS service is running.
• “The resource you are trying to access is not available” after publishing? – The backend URL might be wrong. Make sure it matches exactly what the internal server expects (trailing slash matters).
• MFA prompt not appearing? – Verify the access control policy is applied to the Exchange OWA trust. Use Get-AdfsAccessControlPolicy to list policies. Check that the network location is being classified as extranet (ADFS event logs).
• Client certificate MFA not working? – Ensure the client has a certificate issued by a CA that ADFS trusts. For testing, you can issue user certificates from your internal CA.

11. Next Steps 🚀

You’ve just built a complete secure remote access solution for Exchange. Now we move to the hybrid cloud.

👉 Part 6 – Use‑Case Scenario: Microsoft 365 / Entra ID Federation
We’ll connect our on‑prem AD to a Microsoft 365 tenant via ADFS, enabling true hybrid identity. Users will sign into Office 365 with their corporate AD credentials while MFA and conditional access policies stay on‑premises.