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 (msappproxy.net) or using a custom domain name that is configured on Azure AD (e.g. rdg.contoso.com). 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.