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:
- 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.