Last week Microsoft announced publishing Remote Desktop Services environments through Azure AD Application Proxy. You can read the announcement here. With the Azure AD Application Proxy you can now publish your RD Gateway and RD Web Access Servers using Azure Active Directory authentication. Ofcourse we can also use an on premise Web Application/ADFS environment to publish our Remote Desktop Service environments. In this blogpost I want to show and describe both solutions on a high-level. With these solutions we are able to publish Remote Desktop Services environments with using the rich functionality of Azure AD authentication.

The following diagram shows both Remote publishing solutions in combination with the Remote Desktop Services solutions which currently can be build in your own datacenter and in the cloud:

Windows Server 2012 R2 Web Application Proxy

With the Web Application Proxy, it’s possible to publish Remote Desktop Services which is hosted in the on-premise datacenter but also in the cloud. The changes made in the Web Application Proxy allows the RD Gateway to pick up the session cookie that was used by RD Web Access so the RDP over HTTP traffic is authenticated. With this solution capabilities such as Multi-Factor Authentication and smartcards can be used as authentication mechanism. For the end users, it means that Remote Desktop authentication has the same experience as their Web applications published through WAP. The following diagram shows the solution:

This functionality was introduced in the August 2014 update of the Web Application Proxy. More information can be found here.

Azure Active Directory Application Proxy

With the Azure AD Application Proxy, it’s possible to publish different scenarios of Remote Desktop Services environments. The first option is to publish only the Remote Desktop Gateway, the following diagram shows the components which are involved in this deployment:

In this solution Passthrough authentication is used and no RD Web Access is used/configured. From the Remote Desktop Services Client users can connect to the RD Gateway. When the authentication is successful the connection (RDP over HTTPS) will be made to the Session Host which is in the private network. This solution has the following advantages:

• All RDS server roles can be placed in the private network. So no RD roles need to be deployed in the DMZ network.
• The user can use his existing MSTSC client to make the connection to the RDS environment. The only configuration which need to be done is the RD gateway configuration in the MSTSC client.

The second solution which we can configure with the Azure AD Proxy is shown in the following diagram:

In this solution beside the RD Gateway the RD Web Access is also used in the RDS deployment. Before the users can access the RD Web Access they need to authenticate against the Azure Active Directory. When the authentication is successful the user will be sent to the RD Web Access. When the user then starts his desktop or application the RDP connection is set up through the Azure AD proxy for the RD gateway role with pass-through authentication. When the users start the RDP session, they need to authenticate again over the RDP channel.

This happens because Single-Sign-On from RD Web Access to Remote Desktop Gateway is based on storing the end-user credentials on the client using ActiveX that is triggered from RD Web Access form-based authentication.

This solution has the following advantages:

• All RDS server roles can be placed in the private network. So no RD roles need to be deployed in the DMZ network.
• RD Web Access can be used to present the RDS resources to each user based in their access.

The disadvantage of the above solution is that user need to enter the credentials twice, first for accessing RD Web Access and after that also for accessing the RD Gateway. If RD Web Access SSO to the RDP traffic is needed, it is possible to publish RDWA without preauthentication. The solution will look likes this:

In this solution the users need to authenticate to the RD Web Access using form based authentication but will not need to authenticate against the RD Gateway.

It is important to note that in both cases there is no pre-authentication on the RDP traffic so users may access it without going first through RD Web Access.

More information about the Azure AD Application Proxy and publishing RDS environments can be found here. If you have questions about above solutions please let me know!