New default RD Gateway Resource Authorization Policies in Windows Server 2016

Remote Desktop Services is referred to by Microsoft as one of the “top 10” capability of the Windows Server 2016 release that is going to reach General Availability within a few weeks. Also see this blog post and video Ten reasons you’ll love Windows Server 2016 #4: Remote Desktop Services. The three key pillars of improvement are shown in the diagram below.


While test driving the Technology Preview 5 version I ran into a small new feature as part of the process of adding an RD Gateway server to a Remote Desktop Services Deployment using RDMS.

Since Windows Server 2012, Server Manager can be used to perform scenario based deployments of Remote Desktop Services. As part of this scenario based deployment, an RDS deployment is created consisting of an RD Connection Broker, RD Web Access and RD Session Host. This confirmation of what is created using the wizard is shown below.

After this initial deployment we are able to add additional servers and also add the RD Gateway role.


As part of the process of adding an RD Gateway server to a 2012 R2 deployment, two default policies are also added to the RD Gateway.

- A default Connection Authorization Policy (CAP) is added that simply allows access to the RD Gateway for the group Domain Users. This is to make sure that you can start using RD Gateway immediately, however in production environments I advise to modify this CAP to only allow access by a specific (Active Directory) group of users. This is not changed with Windows Server 2016.

- A default Resource Authorization Policy (RAP) is added that allows access through RD Gateway towards all computer objects of the domain (via the Domain Computers group). Again, this is added to allow easy setup and in production environments I advise to modify this RAP to only allow access to specific resources of your RDS deployment. Below is what this default RAP looks like.


Starting from Windows Server 2012, the RD Connection Broker became the default initial connection hander. This means that any user connecting to an RDS Deployment always makes an RDP connection to the RD Connection Broker first. The RD Connection Broker decides what’s the best RD Session Host to connect to, resulting in a second RDP connection from user to that RD Session Host server. Although this process is completely transparent for the end user, it does mean that the user must be able to access the RD Connection Broker via RDP. For RD Gateway usage, this means that the RD Connection Brokers must be added to the RD RAP as a resource.

The above scenario is where in the future, RDS on Windows Server 2016 helps out. We do the same scenario based deployment of RDS in Windows Server 2016 (TP5), as shown below.

And adding a RD Gateway server to this deployment the same way.

The deployments now adds an additional RD RAP out of the box called RDG_RDConnectionBrokers


This RD RAP provides access to an RD Gateway Managed Group of computers (called RDG_RDCBComputers) which is populated with the RD Connection Broker Server that is part of your deployment.


This is very helpful because adding the RD Connection Broker to the RD RAP, after removing / changing the RDG_AllDomainComputers RAP, is a task I see commonly forgotten in several environments.

But what about scenario’s where the RD Connection Broker is in High Availability (HA) mode or scenario’s with a single RD Connection Broker where the broker FQDN name was changed by using the Set-RDPublishedName.ps1 In those cases it’s even more tricky because the broker FQDN is not a member of the Domain Computers group, it’s not even a Kerberos object in AD.

When adding an RD Gateway to an RDS 2016 deployment where HA in in place, the wizard also takes case of this. In those case an additional RD RAP (RDG_HighAvailabilityBroker_DNS_RR) is added that provides access to an RD Gateway Managed group called RDG_DNSRoundRobin that holds the RD Connection Broker FQDN as shown below.


This matches the RD Connection Broker HA FQDN as configured in RDMS.

It’s a relatively small addition to the scenario based deployment of RDS on Windows Server 2016, but very helpful to provide smoother setup of the RD Gateway role in such environments.

Windows Server 2016 will hit General Availability during Microsoft Ignite in less than two weeks. I’m looking forward to the launch!