If you would like to read the other parts in this article series please go to:
- Microsoft RDS Policies explained (Part 2)
- Microsoft RDS Policies explained (Part 3)
- Microsoft RDS Policies explained (Part 4)
Introduction
Though Microsoft is offering more and more settings via the wizards and directly into the RDS Server Manager Tool, almost all settings are (still) available as a configuration setting within Microsoft Group Policies. As Microsoft decided to place all RDS settings within one folder of the GPO configuration, on a regular basis I meet people that don’t understand which settings should be applied to which item or don’t understand what the setting configures exactly. In this article series I will do a walk-through of the available RDS policies, describe what you configure with it and on which item the setting should be applied.
RDS policy settings location
RDS policy settings can be found both on the Computer Configuration and User Configuration. Many settings are shared between the computer and user configurations, but logically are applied to the machine or user level. You can find the settings under Administrative Tools – Windows Components – Remote Desktop Services independent if you configure them on computer or user level. I will start with the policy options available on Computer Configuration.
Computer Configuration policy settings
When opening the Remote Desktop Services pane within the Group Policy Editor you will see three subfolders.
Figure 1: Remote Desktop Configuration Computer Configuration Settings subfolders
Each subfolder is representing a different component of the RDS Stack. The folder RD Licensing includes settings for the RD Licensing Server component, the folder Remote Desktop Connection Client offers settings applying to the RDP Client, while the Remote Desktop Session Host folder has settings available for the RDS servers. This is one of the mistakes I have seen that settings were applied to the wrong machines. Let’s start with the available RD Licensing settings, which are also displayed in figure 1.
RD Licensing
License Server Security Group
By default an RDS License Server will provide a license to an RD Session Host when one is requested. However this behavior can be changed with the License Server Security Group setting. Enabling this policy setting will cause licenses to be only provided to RD Session Hosts which are members of the (local) RDS Endpoint Server group. When a server is not listed in this group, no licenses will be provided. By default this setting is not configured, which is the same behavior as configuring this policy with the option Disabled (so all license request will be honored and the content of the RDS Endpoint Server group will not be used). If you would like to fully control the license issuance this policy will be useful.
Prevent License Upgrade
The second setting which applies to the RDS License Server is labeled Prevent License Upgrade. By default an RDS License Server will provide an RDS CAL of the same level of the RD Session Host (or 2003 Terminal Server). When such a license is not available the RD License Server will provide an RDS CAL of a higher level. So in the case where there are no 2003 RDS CALs available, but 2008 RDS CALs are available, a 2008 RDS CAL will be assigned. When you enable the setting Prevent License Upgrade no 2008 RDS CAL will be provided to the 2003 RD Session Host client, but a temporary 2003 RDS Call will be issued. In the case where the client has already requested a CAL before and the temporary CAL is expired, the client cannot set-up a connection. Personally, I don’t see any advantages to configure this setting. The policy set to Not Configured or Disabled will provide the default behavior as described in advance.
Remote Desktop Connection Client
The second part is about settings which need to be applied to machines where the MS RDP Client (mstsc.exe, also known as RDC Client) is being started. The following settings are available for Remote Desktop Client.
Figure 2: Remote Desktop Connection Client settings
Allow .rdp files from valid publishers and users’s default .rdp settings
With this setting you can control how users can start a Remote Desktop Connection. When this setting is enabled users can start an RDP connection based on a RDP which is signed by a valid publisher or start a session manually by filling a servername into the RDP client. If you would like to allow only those two connections you should enable the following setting “Allow .rdp files from unknown publishers”. This setting can also be used to disable the usage of RD Client at all by disabling this setting. Then users cannot start an RDP connection manually by typing the server name in the Remote Desktop Client. I can think of situations that you would like to start RDP files form valid publishers, but don’t want users to set up the connection manually. Unfortunately, this is not possible with the current policy settings.
This setting is also available on a user level, but configuring the setting on machine level causes the configuration to be applied to all users.
Figure 3: Remote Desktop Connection not possible by disabling Allow .rdp file from valid publishers and user’s default .rdp settings.
Allow .rdp files from unknown publishers
If you would like that users can only start RDP connections based on the RDP files signed by a valid publisher, you should enable this setting. This will not allow users to start a manual connection via the Remote Desktop Client, only RDP files from unknown publishers will be blocked. Not Configured means that .rdp files from unknown publishers can be started, but a warning message will be shown.
Do not allow passwords to be saved
If you don’t want users to have the possibility to use the checkbox “Remember my credentials” you should Enable this policy setting. The checkbox will be disabled and in the RDP file no passwords will be saved. By default users are allowed to use the “remember my credentials” checkbox. It’s a pity that you cannot achieve similar results using a policy setting on the Session Host in my opinion.
Specify SHA1 thumbprints of certificates representing trusted .rdp publishers
If you are using trusted .rdp publishers, those RDP files should be signed. With the policy “Specify SHA1 thumbprints of certificates representing trusted .rdp publishers” you can provide the system which certificates are trusted for the RDP file. The exact value can be found in the properties of the certificate(s) within the thumbprint field.
Turn Off UDP On Client
By default the RDP Client uses both UDP and TCP to communicate with RD Session Host. With this setting you can configure the RD Client in such a way that it uses only TCP based communication.
Prompt for Credentials on the client computer
Microsoft changed the methodology where a user is asked for credentials when setting-up an RDP session. In Windows Server 2000 and 2003 the user provides the credentials when the session was already set-up (so on the Terminal Server). From Windows 2008 the user will provide the user credentials already on the client, so before the session is presented to the end-user. Enabling this setting allows you to obtain the same behavior for all RD sessions (so also before Windows 2008 versions). When the credentials are saved in the RDP file, the user won’t be prompted for credentials.
Configure Server authentication for client
Server authentication is based on encryption levels, with the highest level using TLS (based on certificates). With the Configure Server authentication for client you configure when the encryption levels don’t match. By default the client warns if the authentication fails, but the connection is set up. You can also set the policy to “Always connect even if authentication fails”, so no warning message is shown or “Do not connect if authentication fails” causing the RDP connection not to be set up.
Summary
In this first part of our article series we discussed possible ways of configuring RDS settings, with policies that override. Also we have seen that RDS policies are both available as computer and user settings. We started describing the computer configuration settings including describing on which component they should be applied. In the second article we will continue with the settings available for the RD Session Host, followed by the available user settings.
If you would like to read the other parts in this article series please go to:
