Forum Discussion

EntilZha's avatar
EntilZha
Iron Contributor
Jan 14, 2026

Setting up MFA for RD Web Access and RD Web Client using ADFS

All servers in our Remote Desktop Gateway (RDG) environment are running Windows Server 2022 (Datacenter and Standard).

 

The RDG environment is fully operational. Users can successfully authenticate to RD Web Access and the RD Web Client, and all published folders and servers are visible as expected. Most servers are configured for direct access, with a few configured as Session Hosts. Overall, everything is functioning correctly except the MFA.

 

Based on my research into integrating ADFS MFA with RD Web Access / RD Web Client, it appears that MFA is only triggered when authentication flows through Web Application Proxy (WAP).

 

Question:

To support MFA for internal users without exposing RD Web externally, I’m considering creating a separate WAP cluster dedicated to internal traffic that would proxy authentication requests to the ADFS servers and trigger MFA.

 

Since I’m still building familiarity with WAP and ADFS, is it supported for ADFS to work with two WAP clusters one handling internal traffic and another handling external traffic against the same ADFS farm?

 

-Larry

Remote Desktop Gateway
windows server

1 Reply

  • Jamony's avatar
    Jamony
    MCT
    Sep 19, 2026

    If I understand the requirement correctly, RD Web/RD Gateway already works, external access already uses WAP, and you want internal users to receive MFA without exposing the internal RD Web endpoint externally.

     

    You don't need to introduce a second internal WAP tier solely to make AD FS trigger MFA.

     

    AD FS authentication policies can require MFA globally or for a specific relying-party trust and can make decisions based on users/groups and network location. In other words, WAP isn't the only mechanism that can cause MFA to occur.

     

    I would:

     

    Identify the relying-party trust used by the RDS/RD Web authentication flow.

    Create/test an AD FS authentication policy requiring MFA for the required users or groups.

    Test it from an internal client before changing your proxy topology.

    Leave the existing external WAP deployment responsible for external traffic.

    Add WAP nodes only where you actually need proxy capacity or availability.

     

    Microsoft describes multiple proxies protecting the same Federation Service as a proxy farm; they use the same Federation Service name.

     

    So I would not build a second internal WAP cluster purely as an MFA trigger. Configure MFA at the AD FS policy/relying-party level first.