1. Objective & Real‑World Context

Now that our ADFS farm is alive, it’s time to plug in a real enterprise application – Exchange Server Outlook Web App (OWA). By the end of this lab, users will browse to https://mail.corp.lab/owa and be seamlessly redirected to ADFS for authentication. No more separate OWA login forms, no more password prompts – just a clean SSO experience driven by AD.

This is exactly how thousands of organisations secure their on‑premises Exchange. We’ll configure Exchange to trust ADFS, set up the relying party trust, and craft the claim rules that make it all work.

2. Pre‑Lab Checklist

• ✅ DC01 & ADFS01 fully configured (Part 3)
• ✅ Exchange 2019 VM (EXCH01) joined to corp.lab, Mailbox role installed
• ✅ OWA internally accessible via https://mail.corp.lab/owa (forms‑based auth)
• ✅ SSL certificate on EXCH01 covering mail.corp.lab (internal CA is fine)

3. Step 1 – Export ADFS Token‑Signing Certificate

Exchange needs to trust the token‑signing certificate that ADFS uses to sign SAML tokens. We’ll export its public key and import it on EXCH01.

1. On ADFS01, open AD FS Management.
2. Go to Service → Certificates. Double‑click the Token‑signing certificate.
3. Switch to the Details tab, click Copy to File, and export as a Base‑64 encoded X.509 (.CER) file. Save it as ADFS_TokenSigning.cer.

Copy this file to EXCH01 (via a shared folder or drag‑and‑drop).

3.1 Import the Certificate on EXCH01

1. On EXCH01, run certlm.msc.
2. Expand Trusted Root Certification Authorities, right‑click Certificates → All Tasks → Import.
3. Browse to ADFS_TokenSigning.cer, finish the wizard. It will appear in the trusted root store.

4. Step 2 – Configure Exchange for ADFS Authentication

Open the Exchange Management Shell on EXCH01 (as administrator). We’ll first disable forms‑based authentication on OWA and ECP, then enable ADFS.

4.1 Disable Forms & Basic Auth, Enable ADFS

# OWA
Set-OwaVirtualDirectory -Identity "EXCH01\owa (Default Web Site)" `
    -AdfsAuthentication $true `
    -FormsAuthentication $false `
    -BasicAuthentication $false

# ECP
Set-EcpVirtualDirectory -Identity "EXCH01\ecp (Default Web Site)" `
    -AdfsAuthentication $true `
    -FormsAuthentication $false `
    -BasicAuthentication $false

After running these commands, OWA’s default login page will disappear. Instead, users will be redirected to the ADFS endpoint we specify next.

4.2 Set Organization AD FS Parameters

Now tell Exchange where ADFS lives and what realm to use. The realm (audience URI) must match the relying party identifier we’ll create in ADFS. We’ll use https://mail.corp.lab/owa.

$adfsUrl = "https://sts.corp.lab/adfs/ls/"
$realm = "https://mail.corp.lab/owa"

# Get the thumbprint of the Exchange OWA SSL certificate
$cert = Get-ExchangeCertificate | Where-Object {$_.Services -like "*IIS*"} | Select-Object -First 1

Set-OrganizationConfig -AdfsIssuer $adfsUrl `
                        -AdfsAudienceUris $realm `
                        -AdfsSignCertificateThumbprint $cert.Thumbprint

Restart IIS to ensure everything takes effect:

iisreset /noforce

5. Step 3 – Create the Relying Party Trust in ADFS

Now switch to ADFS01 and open AD FS Management. We’ll tell ADFS about Exchange OWA.

1. Right‑click Relying Party Trusts → Add Relying Party Trust.
2. Choose Claims aware → Start.
3. Select Enter data about the relying party manually.
4. Display name: Exchange OWA.
5. Skip token encryption certificate (Exchange doesn’t require it).
6. Check Enable support for the WS‑Federation Passive protocol. URL: https://mail.corp.lab/owa/ (note the trailing slash).
7. Add a relying party trust identifier: https://mail.corp.lab/owa (exactly as used in the Exchange AdfsAudienceUris).
8. Leave MFA configuration as default (no MFA for now).
9. Choose Permit everyone → Finish.

The trust is now created. We still need claim rules, otherwise Exchange won’t know who the user is.

6. Step 4 – Configure Claim Rules

Exchange expects certain claims in the SAML token to map the federated user to a mailbox. The most critical is the User Principal Name (UPN), sent as the Name ID claim. We’ll also explicitly send UPN and the Windows account name for good measure.

In the Relying Party Trust properties for Exchange OWA, open the Claim Issuance Policy tab and add these rules:

Rule 1: Transform UPN → Name ID

• Claim rule template: Transform an Incoming Claim
• Incoming claim type: User Principal Name
• Outgoing claim type: Name ID
• Outgoing name ID format: Unspecified

Rule 2: Pass Through UPN

• Claim rule template: Transform an Incoming Claim
• Incoming claim type: User Principal Name
• Outgoing claim type: UPN

Rule 3: Send Windows Account Name

• Claim rule template: Transform an Incoming Claim
• Incoming claim type: Windows account name
• Outgoing claim type: Windows account name

Click OK to save. Now ADFS is ready to issue the right claims to Exchange.

7. Step 5 – Test and Verify

Now the real magic.

1. From a domain‑joined machine (or a browser on any lab VM), browse to https://mail.corp.lab/owa.
2. You should be immediately redirected to https://sts.corp.lab/adfs/ls/... (ADFS sign‑in page).
3. Sign in with a domain user account (e.g., corp\administrator or a test user with a mailbox).
4. After successful authentication, you’ll be redirected back to OWA, which should load your inbox.

Also try the IdP‑initiated flow:

• Go to https://sts.corp.lab/adfs/ls/idpinitiatedsignon.aspx
• Sign in, select Exchange OWA from the relying party list, and you’ll land in OWA already authenticated.

8. Deep Dive: What Just Happened?

When you first hit OWA, Exchange (the relying party) detects no active session. It constructs a WS‑Federation sign‑in request, signs it with the OWA SSL certificate’s private key, and redirects your browser to ADFS with that request.

ADFS authenticates you against Active Directory (Kerberos if inside the domain, or forms login). Then it queries AD for your attributes, runs the claim rules we defined, and issues a SAML token containing your UPN (as NameID) and other claims. The token is signed with the ADFS token‑signing certificate.

Your browser posts that token back to Exchange OWA. Exchange validates the signature (using the token‑signing certificate we imported), extracts the NameID/UPN, and maps it to a mailbox. Session cookies are created, and you’re in.

9. Troubleshooting Common Pitfalls

• Redirect loop or blank page after login? – Ensure the relying party passive URL ends with /owa/ and matches exactly. Check that the AdfsAudienceUris in Exchange matches the relying party identifier.
• “Couldn’t find a mailbox” error? – The user’s UPN (NameID) might not map to their mailbox. Verify you’re sending UPN as Name ID, or add a rule to send the E-Mail Address claim.
• Token‑signing certificate trust? – Make sure the token‑signing cert is in EXCH01’s Trusted Root store. Check the ADFS event log for signature validation errors.
• Forms authentication still showing? – Did you run both Set-OwaVirtualDirectory and Set-EcpVirtualDirectory? Restart IIS after changes.
• ADFS event log? – Always check AD FS → Admin for detailed errors. If you see “MSIS7065: No authentication context”, double‑check the passive URL.

10. Next Steps 🚀

Fantastic work! You now have Exchange OWA federated with ADFS. Users get a true SSO experience, and IT retains control. But right now, this only works inside the corporate network.

👉 Part 5 – Use‑Case Scenario: External Access with Web Application Proxy
We’ll publish OWA securely to the internet using the ADFS Web Application Proxy (WAP), simulate a DMZ, and even enforce Multi‑Factor Authentication for external access.