This is the last blogpost in the series of publishing your RDS environment with Azure AD Application Proxy. In the first post of this series I’ve described the steps needed to configure Azure AD Application Proxy pass-through authentication to publish a RDS environment. In the second post of this series I’ve focused on pre-authentication and explained the steps needed to configure pre-authentication for a RDS environment. In this last part of the series I’m focusing on High Availability of both the RD Web and RD Gateway roles and the Azure AD Application Proxy. I’m ending the series with sharing some excellent guidance provided by Microsoft of designing your Azure AD Application Proxy environment.

Let’s first focus on high availability. When deploying your RDS environment on Microsoft Azure High Availability is an important topic. Single instance VMs does not have any SLA. So if you want to have a SLA on your Virtual Machines you should deploy at least 2 instances of each role and put them behind a load balancer. More information about pros and cons of deploying your RDS environment on Azure can be found in this blogpost.

Pass-through authentication:

In the first blogpost of this series I’ve described which steps are needed to configure the Azure AD Application Proxy with a single RD Web/RD Gateway server. In a high available environment 2 servers are needed both load balanced by a Load balancer. You will also need 2 Azure AD Application Proxy Connector servers. In a production environment I would advise to install the Azure AD Application Proxy connector role on 2 dedicated virtual machines. If deployed on Microsoft Azure the servers need to be placed in an availability set. A graphical representation of a high available solution will look like this:

Based on the configuration described in the 1^st post the following changes need to be made to make the environment high available:

• Create an Azure Load balancer and configure both RD Web/ RD Gateway servers as the backend pool. Configure load balancing rules for both port 80 and 443.
• Change the internal DNS entry of the RD Web and RD Gateway to the point to the IP of the internal load balancer.
• Install the Azure AD Application Proxy Connector software on 2 dedicated virtual machines and place them in the same Azure AD Application Proxy Connector group.

With above configuration the environment is made high available and can be used with pass-through authentication.

Pre-authentication:

The short-story is that the Azure AD Application Proxy pre-authentication with SSO solution for publishing the RD Web/RD Gateway cannot be made high available at this moment. In the 2^nd post I’ve described the pre-authentication scenario with the creation of the Service Principal Name(SPN) which will be used to do the SSO from Azure AD Application Proxy to the RD Web feed. In the second part of this series we’re used a single RD Web/ RD Gateway and the SPN was configured on the AD computer account of that server. When using multiple servers in a high available scenario the SPN cannot be registered to that single server. It’s also not allowed to register the same SPN on multiple computer accounts in the AD, so the only solution is to register the SPN on an AD user account and run the RD Web under that user account. At this moment that is not possible in Windows Server 2016. So based on that reason the pre-authentication solution with SSO to the RD Web feed cannot be made high available.

Another option you will have is to use pre-authentication in combination with the form authentication of the RD Web Page. In this scenario the user needs to logon in the pre-authentication stage and after a successful logon the user will be redirected to the RD Web login page. On that page the users need to logon again and after that logon SSO will until the user is logged in his desktop. With this scenario you can use pre-authentication and use your high available RD Web/RD Gateway environment.

Let’s finalize this series with looking into some design guidance around Azure AD Application Proxy. Microsoft recently published some very good reference blogposts:

• Network topology considerations when using Azure AD Application Proxy
• Security considerations when using Azure AD application proxy

It’s not my intention to include the complete posts in this blogpost but based on those blogposts I want to share some basic information and considerations regarding the RDS scenario:

Network Topology:

The basic Azure AD application Proxy structure is based on 3 hops as shown in the picture below:

The first Hop 1 is the user connecting to the Azure AD App Proxy service, the second hop is between the Azure AD App Proxy service and the Connector and the last hop is from the connector to the application. Based this picture it’s important to take the following design considerations into account:

• The Region of your Azure AD is very important because your Azure AD Application Proxy service will be hosted in this region. So If you’re planning to deploy your service in Europe your Azure AD tenant should also be hosted in Europe to reduce latency;
• Reduce the ‘distance’ between the hops as much as possible. So if you’re application is hosted within your own on premise environment the connector should be installed in the same network. Golden rule is install the connector always as close as possible to your application environment;
• Make use of private connections where possible. If your application is located on premise think about using ExpressRoute instead of routing the traffic over the public internet.

More detailed scenarios and information can be found in the blogpost mentioned above.

Security Considerations:

The goal of the above blogpost is to provide the security teams enough context to understand how Azure AD app proxy provides a secure service for publishing and accessing your applications. I want to write down the most important considerations based on the RDS scenario:

• Azure AD app proxy is best suited to publish applications with pre-authentication, but in the RDS scenario this can only be used when a single RD Web/ RD Gateway is used. If the environment needs to be as high available as possible pass-through authentication is the only option;
• All traffic is terminated in the cloud; this means that the RD Web/RD Gateway are not exposed to direct HTTP Traffic from the outside world;
• The connectors maintain outbound connections to the Azure AD App proxy service, this means there is no need to open firewall ports for incoming connections to the RD Web/RD Gateway
• Azure AD Application is a service so Microsoft will take care of applying the latest security patches to the service.

More detailed scenarios and information can be found in the blogpost mentioned above.

Conclusion:

With this last blogpost I’m ending a series of blogposts around Azure AD Application Proxy and publishing your RDS environment through the proxy. I really like the possibilities we get with the Azure AD Application Proxy. As already mentioned I really like the pre-authentication with SSO functionality, but we cannot use that together with a high available RDS environment. So this means if you have a small environment you should really look into pre-authentication, if you want to have a high available solution but want to benefit from the security improvements of Azure AD Application Proxy you should use pass-through authentication or pre-authentication with a second logon to the RD Web. If you have any questions based on this series of posts, please let me know!