This is 6th edition in a series of articles on this blog related to the automatic deployment of RDS on Azure IaaS using ARM and JSON. This edition is related to the further configuration of the RD Gateway role and is based on what was covered here before. I won’t go into detail here again on what was covered in previous articles but for completeness, here are the links of those previous 5 articles. PART1, PART2, PART3, PART4, PART5.
So, now that we have an entire RDS deployment which is HA, with SSL certificates configured, based on a custom template image I thought it would be a good idea to add additional configuration for the RD Gateway role. When installing the RD Gateway as part of a RDS deployment starting from Windows Server 2012, two default configurations rules are added to the RD Gateway that help to directly start using the RD Gateway role. With Windows Server 2016 one of these default rules has been expanded as well. For more details on that, also see: New default RD Gateway Resource Authorization Policies in Windows Server 2016.
So what is created by default?
- 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. With Windows Server 2016 a RAP is also added to allow access the RD Connection Broker DNS name (when in HA) and RD Connection Broker servers.
To summarize, by default the RD Gateway will allow all domain users to access all domain computers via the RD Gateway. While this does not necessary have to be a security issue, I would always advise to remove or disable these default rules and add new rules that specify explicitly the group of users that is allowed to access a specific group of resources. This is exactly what this addition to the ARM / JSON template will add.
A couple of new parameters have been added to the ARM template to allows us to specify the properties of the rules to be created inside the RD Gateway role.
RDGWRAPName
Specifies the name of the RD Gateway Resource Authorization Policy (RAP) that will be created
RDGWCAPName
Specifies the name of the RD Gateway Connection Authorization Policy (CAP) that will be created
RDGWDeploymentAuthorizedADGroup
Specifies the group of users in Active Directory that you want to allow access through RD Gateway
RDGWManagedGroup
Specifies the name of the RD Gateway Managed Group of resources that will be created. This Gateway Managed Group will be populated with the necessary destinations to allow access the RDS environment.
The RD Gateway configuration we are aiming to perform is based on PowerShell. In order to run an automated PowerShell script as part of ARM we leverage the CustomScriptExtension and specify the PowerShell script that contains the CmdLets. The parameters specified above will be passed on to this PowerShell script using the commandToExecute property.
The PowerShell script itself imports the RemoteDesktopServices module to be able to use the New-item and Remove-Item Cmdlets to modify the RD Gateway polices. For more information on this topic also see: https://blogs.technet.microsoft.com/ptsblog/2011/12/09/extend...
As a first step the existing RD CAP and RD RAP rules will need to be removed. Again, we do this because the combination of these two rules allows all domain users to access all domain computers via the RD Gateway.
The name of the default RD CAP (in Windows Server 2016) is RDG_CAP_AllUsers. The CmdLets below will take care of the removal of this RD CAP.
In Windows Server 2016, based on a HA environment of the RD Connection Broker role, 3 default RD RAP rules are created. These will allow access to the RD Connection Broker servers (for the initial connection), the RD Connection Broker DNS name (because it is in HA) and AD group Domain Computers. The CmdLets below will take care of the removal of these RD CAP’s.
Now that we have a clean sheet we can start to create our own custom RD CAP and RD RAP rules based on the parameters passed via the ARM template.
The creation of the RD CAP rule is performed by a single CmdLet. Using this CmdLet a new RD CAP is created that is configured to allow members of the specified group access to the RDS environment.
Before creating the RD RAP, we need to create the RD Gateway Managed Group that contains a list of destination resources that we explicitly allow access to. This is performed by the following CmdLets.
After that the New-Item CmdLet can be used to add the necessary resources to this RD Gateway Managed Group. Based on the HA environment we are creating we need to add the following resources:
- The RD Connection Broker DNS name
- The RD Connection Broker servers
- All of the individual RD Session Host servers
Because the ARM template has created each of the objects above it is already aware of these names and is able to pass them as parameters to the PowerShell script.
The final step is to create the RD RAP based on the same AD group of users and specifying the RD Gateway Managed Group we created previously.
Let’s take a look at the results in the RD Gateway Manager.
The default RD CAP rule is removed and a new RD CAP rule is added with the name that was specified in the ARM template and allowing access to members of the group as specified in the ARM template.
The 3 default RD RAP’s have been removed and a new RD RAP is created with the name that was specified in the ARM template and providing access to the new RD Gateway Managed group containing the resources we specified above.
When logging on to the RDS environment as a test user, we can confirm that the new RD CAP and RD RAP policies are working and are allowing access for our testuser which is a member of the authorized group.
The RD Gateway monitor also confirms the active session through the RD Gateway with the new RD CAP and RD RAP in place.
To summarize, in this blog post we have covered additional configuration of the RD Gateway role by removing the default policies and creating new custom policies. This allows us to make sure the RD Gateway is only used by authorized users based on an Active Directory group and that these authorized users can only access authorized resources via the RD Gateway.
No comments:
Post a Comment