Publishing Remote Desktop with Azure Active Directory Application Proxy

Azure Active Directory Application Proxy enables making Remote Desktop deployments accessible for remote users. Such Remote Desktop deployments can reside on-premises or at private network such as IaaS deployments.

Remote Desktop protocol traffic can be published through Application Proxy as a pass-through proxy application. This solution solves the connectivity problem and provides basic security protection such as network buffering, hardened Internet frontend and DDoS protection.

Within the Remote Desktop deployment, the Remote Desktop Gateway is published so it will be able to convert the RPC over HTTPS traffic to RDP over UDP traffic. The clients will use their Remote Desktop clients (MSTSC.exe) to access Azure AD Application Proxy that would start a new HTTPS connection to the Remote Desktop Gateway using its connectors. That way, Remote Desktop Gateway will not be directly exposed to the Internet and all HTTPS requests will first be terminated in the cloud.

Here is the overall topology:

From the user’s point of view, they would simply trigger RDP traffic as they do today using files or other methods as long as they are configured with the Remote Desktop Gateway URL.

Publishing can be done either using the domain name provided by App Proxy ( or using a custom domain name that is configured on Azure AD (e.g. If your client devices and RDP file are already configured with a Remote Desktop Gateway URL, you might want to use the same domain name and avoid the change. In this case the certificate that covers this domain should be provided to Application Proxy and its CRL should be accessible over the Internet.

If no Remote Desktop Gateway URL is configured, users or admins can specify it in the Remote Desktop clients (MSTSC):


 If your organization is using Remote Desktop Web Access (RDWA) portal, you can also publish it using Azure AD Application Proxy. This portal can be published with preauthentication and signle-sign-on (SSO).  

This is the configuration of such topology:

In this case the end users will be authenticated on Azure AD before accessing RDWA. If they are already authenticated on Azur AD, for example because they are using Office 365, they would not have to authenticate again for RDWA.

When the users starts the RDP session, they need to authenticate again over the RDP channel. This happens because SSO from RDWA to Remote Desktop Gateway is based on storing the end-user credentials on the client using ActiveX that is triggered from RDWA form-based authentication. When RDWA authentication is using Kerbros, no form-based authentication is presented and the RDWA to RDP SSO doesn’t work.

If RDWA SSO to the RDP traffic is needed or RDWA form-based authentication was heavily customized, it is possible to publish RDWA without preauthentication:

In this case the end users will need to authenticate to RDWA using form based authentication but will not need to authenticate over RDP.

It is important to note that in both cases there is no preauthentication on the RDP traffic so users may access it without going first through RDWA.

Comments (13)

  1. Marcus Robinson says:

    On your screenshot with the RD Gateway settings you have http://FQDN . I don’t believe you need/can use the https:// in the server name box, just need the FQDN on its own.

    Also I am a little confused re the options – we want to use Azure MFA.I correct in saying we will need to have two proxy applications? One to a RDWeb deployment with AAD pre auth and MFA enabled for external access and another to a RD GW server with passthrough?
    Or can we do Azure MFA with just RD Gateway?

    Many thanks,


  2. Anonymous says:

    2015年10月14日付で、本社の Application Proxy Blog に以下の記事が公開されました。 Publishing Remote Desktop with Azure Active

  3. Robin Curtis says:

    How do we configure AAD Application for RDG? Standard Application proxy is not working and fails to connect. Any documents?

  4. Ian Fraser says:

    Is there any information on how the RDWeb should be configured? Do I need to make any changes to allow configuration of the SPN’s?

  5. Ray Ellington says:

    I cannot get an RDP connection to use UDP when it’s passed through the Azure AD Application Proxy. Using MSTSC.exe if I connect directly to the Remote Desktop Gateway the Gateway uses UDP for the connection to the RDP host. But if I modify that same connection to point to the Azure AD Application Proxy the RDP gateway shows the connection as RPC-HTTP.

    All necessary ports are open from the Azure AD Application Proxy Connector to Azure. The Azure Application Proxy Connector and RDP Gateway are on the same subnet with no firewalls (host or edge) between the two.

    1. Tony says:


      I am also interested in this. Did you ever figure it out? When I use AD app proxy, the RDGW reports that the connections are over RPC (in the event viewer)


  6. David Sampson says:

    Hi Guys, great article thanks. Are there any additional performance requirements for the connector servers when using this for RDP? Should we expect any additional latency using AAP for RDP? If a user is connecting from another region to AAP do they connect to a local POP and gain the benefit of reduced latency over MS networks?

  7. David Sampson says:

    I was hoping to use pre-auth at RDWA to enforce Azure MFA when accessing an application. My understanding though is that RDWA is just a navigational tool and anyone who knew the settings or had a previous rdp file could circumvent the RDWA and be directly passed through the AADAP to the RDG therefore not enforcing MFA. Is there any way to control this, any TS or RDG security/policy settings that ensure only clients that have clicked through from RDWA can access the RDG?

    1. Paul Mooij says:

      Hi David,
      I was struggeling with the same thing; we need to have guaranteed MFA, also when bypassing RDWA using RDP directly.
      I ended up with a MFA server demanding MFA from within the domain, however performing MFA through Azure MFA
      Not sure whether this would fit for your, but the followig page helped me setting this up:

      1. David Sampson says:

        Thanks a lot I’ll take a look into this.

  8. JD says:

    I too am looking to publish RDWA using Azure AD Application Proxy. However, one simple question I have is where should the App Proxy connector be installed? We have on-prem ADFS in our internal network and Web Application Proxy servers in a DMZ. Can the App Proxy Connector be installed on the ADFS server or should they be installed on a separate server? Can the app proxy connector be installed on the Remote Desktop Services (which also host the RDG and License Server) server?

    Any help is greatly appreciated.

    Thank you,


    1. JD says:

      I should note that I have the App Proxy Connector installed on the same server as our Azure AD Connect install. Is this in line with best practices?

  9. Javier Dalzell says:

    Can I configure RDG Proxy App to use Azure Authentication instead of passthrough? in my scenario the passwords should only be stored in azure ad and not in the on prem AD which is where the RDS components are installed.

Skip to main content