This title is a mouthful and obviously aimed more at the Google spiders than the target audience. If I was going to give this post a human readable title, that title might be, “Where did the Device Restrictions option go when I moved to a central Network Policy Server?”. That is also a long and tedious description so I’ll just get to the point.
If your RDS based Virtual Desktop solution does not leverage an RDS Gateway with Multi-factor authentication then I recommend you consider that at once!
For those that have, you will know that you need one or more remote Network Policy Servers with the Azure MFA extension as you can not deploy the Extension on the local RDS Gateway.
Today I had a client with a very specific requirement I have never had before. How to allow only a small group of users to print to their home printers from their Virtual Desktop. At first, I thought this was a very straightforward request but it ultimately led me to authoring this post.
Remote Desktop Device Restrictions control whether or not users can redirect their printers, drives. clipboard or USB microphones and scanners.
Device restrictions can be defined in multiple places within a Remote Desktop deployment. Each have their pros and cons.
Via machine Group Policy – Defined here it is the most restrictive configuration.
Configured at the machine level. If we block printer redirection, all the virtual machines / session hosts inheriting this policy will block printer redirection irrespective of the collection, gateway or Remote Desktop client settings. This will not achieve the required outcome.
Via the collection settings – Defined here it will affect all users logging into their desktop through that collection.
Collections are scoped to groups of users but preside over all of the desktops assigned to the collection. This is inefficient as one wouldn’t want to limit the desktops a user could log into simply to meet the customer requirements. This will not achieve the required outcome.
Via the RDP client settings – Defined here it will affect a single user.
Restricting redirected printing to un-managed and un-audited user printers in the home office is a privilege. It should be enabled carefully.
By default the RDP client will inherit the collection settings anyway. This will not achieve the required outcome.
Via the RDS Gateway – Defined here it affects connections made “through” the Gateway.
Here, device restrictions can be applied to one or more user groups. The only location in an RDS Farm where this appears possible (let me know in the comments). All connections in my scenario traverse the Gateway so this would achieve the required outcome.
When I went to configure the device restrictions, because I was forwarding to a central Network Policy Server, I did not see the option to define the device restrictions.
Here is the view for a locally managed Network Policy Server. Under policies we see the Connection Authorization Policies (CAP) node and from here we can create a new CAP which contains the device redirection policies we want to define for a group of users.
But, we are not using a local RDS Gateway. We are using a central Network Policy server hosting our Azure MFA Extension. If we look at that configuration we do not have a Connection Authorization Policies node. We have a node called Central Network Policy server and this does not provide an interface for defining Device Restrictions. So the question is how to have ones proverbial cake and eat it too.
I started by building a lab and looking back at a stand-alone local Network Policy Server Configuration. Here we can see that when we create a CAP it updates the underlying network policy server as shown below.
Opening the Network Policy Server MMC we can see that the Gateway Manager MMC has created a Network Policy. If we look at that Network Policy we can see there is a very important and interesting vendor attribute on the policy called TSG-Device-Redirection.
I looked this Microsoft attribute up. The link is below:-
Here we can see that this is a bit data type. Therefore no drives + no printing + no clipboard would equal a 15 bit value.
Repeating the steps above lets look at our intended configuration where we want a small group of users to be able to print to their local, home, printers. Here we can see the bit value is 13 bit value.
Brilliant! So armed with this information, I went back to my central Network Policy Server and configured the same policies and was pleased to see the TSG-Device-Redirection vendor attribute waiting. I then setup the policies controlling who could print locally and who could not.
A few key points before we begin testing and documenting the results of the changes above.
Policies are implemented in order until a match is found. So your least restrictive policy should always be at the top.
This is especially relevant as you will likely have a group containing all users which is allowing RDS Gateway / Collection / Virtual Desktop access. Without needing to change that we can add our less restrictive policy above and the user can exist in the original group as well as the one granting printer redirection.
Another point. As you can see, there is no group policy, collection or RDP client setting restricting printer redirection. All are enabled at these levels. It is the central Network Policy Server and the RDS Gateway that will now enforce the device restrictions.
Test 1 – Adding the sample user to the security group associated with the No Printers, Drives or Clipboard Policy on the central Network Policy Server. At logon my local printer is not redirected as expected.
Test 2 – We then add the sample user to the security group associated with the No Drives or Clipboard Policy on the central Network Policy Server. At logon my local printer is redirected as expected. Client requirement met.
I hope this helps!