In the coming series of blogposts, I want to focus on publishing your RDS environment through the Azure AD Application Proxy. Publishing your RDS environment with the Azure AD Application Proxy has several advantages compared to publishing it without the Azure AD Application Proxy. This blogpost will cover the advantages and disadvantages of publishing your environment through the Azure AD application Proxy and this part will also cover the configuration of Azure AD Application Proxy with pass-through authentication. In the next blogpost I want to focus on pre-authentication with Azure AD and in the last part I want to focus on making all components high-available. All blogposts are based on Windows Server 2016 TP5 which is in public preview at this moment.
So in this blogpost I want to focus on reasons why you should use the Azure AD application proxy for publishing. The first reason is that with the Azure AD Proxy no public endpoints are needed on your RD Gateway and RD Web servers. So these roles can be placed in your internal LAN and the traffic will be routed through the Azure AD Application proxy to both server roles. Let’s show this in a more graphical way J. If you should deploy an RDS environment without the use of Azure AD Application Proxy, the deployment will look like the image below:
A Windows Server 2016 environment optimized on Azure will look like this:
The above picture shows the use of Azure AD Application Proxy and the use of Azure SQL Database. More information about using Azure SQL Database can be found here. But how do we configure the above scenario using pass-through authentication. With Azure AD Application Proxy there are 2 types of authentication. With Azure Active Directory authentication, the Application Proxy redirects users to sign in with Azure AD, which authenticates their permissions for the directory and application. With Pass-through authentication users don’t have to authenticate to access the application. In this case the authentication should be done on the application itself. If you follow the steps below your RDS environment will be published through the Azure AD Application Proxy. Important to mention that basic knowledge of Azure AD Application Proxy convenient. In the steps below we configure 2 applications. For the RDWeb we need to create a application for the URL ‘servername.com/rdweb’ and for the RD Gateway we need to create a application with the URL ‘servername.com/rpc’. Now let’s start configuring pass-through authentication:
- The first step is to configure synchronization between your Active Directory and Azure Active Directory if this is not already in place. Guidance how to configure this can be found here.
- First you need to logon to the https://manage.windowsazure.com with an account which is a global admin on your Azure Active Directory and go to the ‘Configure’ section:
- To enable Azure AD Application Proxy go to the corresponding section and enable to option below:
- The next step is to download the connector software from the link in this section and install the connector on one of your servers. In my environment I’ve installed it on my RDGW server. In Part 3 I want to cover the best practices and High-Availability. But for now it will work to install the client on the RD Gateway server. The installation is fairly simple and therefore not described in this blogpost.
- When the connector is installed it should appear in the view when you click on Manage Connectors:
If something is wrong, you will see the following screen:
or
- So the next step is to create 2 applications in Azure AD. You will need to create an application for the RD Web and for the RD Gateway even if both roles are hosted on the same server. Let’s start with creating the RD Web Application. Go to Applications and click on Add. In the popup window select ‘Publish an application that will be accessible from outside your network.
- In the next screen enter the application name and the internal URL of the RD Web. For simplicity I used the same URL for both inside and outside the network. In my internal DNS system I created a split-brain DNS entry.
- Next step is to configure the external URL to use your own external domain and configure the certificate for this domain:
If you don’t have an external certificate you can just use the ‘standard’ URL provided by Azure AD Application Proxy.
- The next step is to grant access to this application in the Users tab of the application.
- Now your RD Web application is created the next application to create is the RD Gateway application. The creation of the application is the same only the URL will change
NOTE: If you don’t use your own custom domain like I do in the above example, you will have to change the RD gateway URL in your RDS deployment. The RD gateway URL in your RDS Deployment should be the same as the external URL in this application. - Now both applications are created the next step is to create the CNAME entry in your DNS provider of your public domain name. This CNAME should point to the URL which can be found in the application.
Now let’s take a look into how this will look like for the end-user:
The user will be routed through the Azure AD Application proxy to the RD Web environment, pass through authentication is configured so the user should see the login prompt of the RD Web. The user can now logon to the RD Web.
After the login the user will see his resources and can start those resources. After clicking on the resource the user should be able to logon to the resource with SSO from the RD Web. With this configuration, the sign-on experience remains identical to the way it was before: you can still have Web SSO when logging in through RD Web with Internet Explorer.
As you can see in the above picture I’m connected to my resource and the connection quality is good. You probably will also notice that the UPD channel is not enabled. The only disadvantage of using the Azure AD Proxy is that the UPD channel cannot be opened. This will mean that you don’t have the RemoteFX WAN optimizations. But in the end using the Azure AD proxy will give you a more secure environment since both the RD Web and RD Gateway doesn’t have to be published to the internet.
Great stuff, looking forward to the next installment!
I can get to the RDWeb website, but I can’t connect to any of the applications. Is there anything to setup on the RDGateway itself? Because I feel like the requests aren’t being proxied.
Thanks!
Hi Tim,
Your RD Gateway URL in your RDS deployment must be the same as in your RD Gateway Azure AD application.
No additional actions are needed for the RD Gateway in a pass-through scenario.
Regards, Arjan
Thank you!
Hi. Thx.
It’s working great.
But isn’t there a security problem with the RDGW configured in passthrough.
I can open a normal MSTSC and use the RDGW as proxy and connect to the internal servers this way.
One of the good thing i tried to get out of this solution was MFA. You can do that on the RDWeb. But how to protect the RDGW with MFA or secure it against direct connections.. ?
Regards, Lars
Hi Lars,
The security problem you’re referring is the same when you publishing the RD gateway directly to the internet. You need to configure policies on your RD Gateway which allow or deny connections to Internal Severs. When using pass-through authentication, I want to advise you to enforce MFA on the RD gateway instead of the RD Web. This will protect you against direct connections.
Regards, Arjan
Hi Arjan,
Could you please expand on this further? This is a major security risk. Most people would be using this process (thank you by the way, very helpful) to setup AzureAD MFA for RDS. However, If I save the RDP file to my local PC, I can simply run this file, and totally bypass RDWEB and therefore 2FA.
I have tried changing the pre-authentication to AzureAD on the gateway app proxy, but this did not help, I simply could not login anymore. Any chance you could assist further with this, I think, important consideration?
Hi Ryan,
The only way to get this fixed is enforcing MFA on the RD Gateway. When you configure MFA on the RD Gateway each connection needs to do a MFA request.
Regards, Arjan
Hi Arjan,
Sorry but I am not sure how to achieve what you are suggesting, hence my request for some clarification. Do you mean we should change the pre-authentication to AzureAD on the RPC profile, instead of passthrough?
Or are you suggesting a more significant, out of scope (in context of this article), method to apply MFA on the Gateway?
Many thanks for your help.
This looks great – however does the use of the external URL mean that a port forward is still required on your firewall to access that internal resource? If it is what’s to stop a hack aiming for that directly and bypassing Azure Application Proxy?
Hi Neil,
When using the AzureAD Application Proxy no port-forward to your internal LAN is needed. The AzureAD Application Proxy only uses outbound traffic from your internal network to the AzureAD application backend. In my blogpost you can find the instructions to configure this configuration, let me know if something is missing.
Regards, Arjan
Great info thanks. Using Azure App Proxy I can get to the RD Web page but starting an app fails with “Remote Desktop can’t connect to the remote computer….”.
Can you try to set-up a session from your AzureAD Application Proxy connector and then try it again from the internet. I’ve seen a couple of times that I first needed to logon from internal and then after that external logins through the AzureAD Application Proxy started to work.
Let me know,
Regards, Arjan
Thanks, that worked.
Hello Arjan,
(Of moet ik zeggen hallo Arjan (-:)
I’m having severe problems getting this working. New to both RDS and Azure AD AP.
I have created the two applications with the default Microsoft domain names and get to the RDWeb page just fine. The /rpc/ works in the sense that it gives me a blank page but no errors.
I cannot access any RemoteApp however. This seems because only internal names are used and they are resolved externally where they do’nt exist. The RDP connection that opens points to internal names for both “remote computer’ and ‘Gateway server’.
I would expect this to be working because we are using the AAD AP but from the certificate error we receive we can conclude that is trying to connect to our external website, which is logical because the host does not exist externally.
I’v tried adding a cname for the internal name, pointing to the xxxx-xxx.msappproxy.net applications but this has no effect.
Internally everything is working fine.
Probably some gateway misconfiguration but I have no idea, just did a next-next-finish deployment (-:
If you’re using the msappproxy.net it becomes difficult because RDS is heavily relying on certificates. As you can see I’m using a custom domain within my blogposts and using a split DNS configuration in my internal DNS configuration. This way you can easily configure RDS with your external DNS name certificates and configure the AzureAD App Proxy with those certificates.
If you want to configure this with the names it’s possible but a lot harder to configure. Let me know if a I can help, drop me a message on avroege at vroege dot eu.
Regards, Arjan
When trying from internet getting “remote gateway server temporarily unavailable’. Tested from Internal network using Gateway and its working. RD Gateway and azure proxy urls are same. Any thoughts?
Can you try to set-up a session from your AzureAD Application Proxy connector and then try it again from the internet? What URL did you entered in the AzureAD App Proxy configuration?
Regards, Arjan
I have the same issue Arjan. I can connect perfectly fine from LAN network but not from internet using AAD proxy. I am using both gateway and webaccess msappproxy.net url’s only.
Hi Arjan,
My objective is to create environment which uses Azure AD Application Proxy, Azure MFA and on-premises RDS deployment (RemoteApp). MFA works just fine and also RD Web Access with SSO.
Problem here is that when I run PS command on Broker (Set-RDSessionCollectionConfiguration -CollectionName “” -CustomRdpProperty “pre-authentication server address:s:`nrequire pre-authentication:i:1”). RD Gateway doesn’t work. Error message is “Your computer can’t connect to the remote computer because authentication to the firewall failed due to missing firewall credentials…” I have not being able to resolve this.
How can I configure RDGW to use pre-authentication on AAD or on-premises ADFS?
Thanks in advance!
Hi, for anyone coming across this post, I found you can have a single Azure app for both RD Web and Gateway (on same box), enforcing Azure pre-auth for both. This disallows bypassing using RDP connection with gateway set. But you must use IE with the active x plugin to provide the SSO from web to gateway. I followed the steps below, works perfectly. Although you have to authenticate again on the RDWeb page, it does achieve the goal of enforcing MFA.
https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-integrate-with-remote-desktop-services
Regards,
Simon