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.

• ✅ 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

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

WAP01 – Installing Web Application Proxy role

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).

Export Root CA certificate from ADFS01

Import Root CA certificate into WAP01 Trusted Root

Now WAP01 will trust the SSL certificate presented by ADFS01.

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.

WAP Configuration Wizard – ADFS server name

WAP Configuration Wizard – Credentials

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

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).

Publish New Application – General Settings

Publish New Application – External/Backend URLs

Complete the wizard. The application will show as Published.

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.

Browser showing OWA inbox after external access via WAP

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

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 (PowerShell)

On ADFS01, open an elevated PowerShell console and create a policy that enforces MFA when the network location is not intranet:

# Define the policy (checks if request is from extranet)
$policy = @"
@RuleTemplate = "AllowAllAuthzRule"
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

@RuleTemplate = "RequireMFA"
=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/mfacontrol", Value = "RequireMFA");
"@

# Create the access control policy
New-AdfsAccessControlPolicy -Name "Require MFA for Extranet" -Policy $policy

PowerShell – Create Access Control Policy

8.2 Apply the Policy to the Exchange OWA Relying Party

# Apply the policy to the OWA relying party trust
Set-AdfsRelyingPartyTrust -TargetName "Outlook on the web" -AccessControlPolicyName "Require MFA for Extranet"

Apply Access Control Policy to OWA trust

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. Enable it with:

Set-AdfsGlobalAuthenticationPolicy -MultiFactorAuthentication CertificateAuthentication

Enable Certificate Authentication for MFA

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.

MFA prompt – client certificate selection

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.

• 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.
• WAP doesn’t forward requests after authentication? – Check that the WAP service account has permission to read the relying party trust. Also verify that the backend URL is reachable from WAP.

If you need to quickly disable MFA or remove the WAP publishing, here are the steps:

11.1 Disable MFA for Extranet Access

On ADFS01, in PowerShell:

# Remove the access control policy from the relying party
Set-AdfsRelyingPartyTrust -TargetName "Outlook on the web" -AccessControlPolicyName $null

# Optionally, disable certificate authentication globally
Set-AdfsGlobalAuthenticationPolicy -MultiFactorAuthentication $null

This will revert to standard password‑only authentication for all users (intranet and extranet).

11.2 Remove the Published Application from WAP

On WAP01, open Remote Access Management, find the published application, right‑click and select Remove. Alternatively, use PowerShell:

# List published applications
Get-WebApplicationProxyApplication

# Remove the OWA application (replace the name if different)
Remove-WebApplicationProxyApplication -Name "Exchange OWA (External)"

11.3 Disable WAP Proxy Trust (if needed)

On ADFS01, you can remove the proxy trust:

# List proxy trusts
Get-AdfsProxyTrust

# Remove the specific proxy (use the name from the list)
Remove-AdfsProxyTrust -Name "WAP01"

After these steps, external access will be blocked until you reconfigure publishing. Internal access via direct OWA URL remains unaffected.