Thoughts from the EPS Windows Server Performance Team
Useful Microsoft Blogs
Hello AskPerf readers. I am Edwin Rocky and this time I am back with some interesting information about the “Allow Logon through Terminal Services” group policy and “Remote Desktop users” group.
I am sure many of you are already familiar this GPO and this group. But still there has been some confusion around whether you should be using the GPO for allowing the user to RDP to the server or should be using the Remote desktop users group or both. And at times, even what to choose between them and what is the best recommended practice.
Hence I wanted to provide a short simple explanation about this group policy and the user group and how they are interrelated.
To start with, there are two types of user rights; Logon rights & Privileges. In simpler terms these are:
1) Remote Logon: rights to machine
2) Logon: privileges for access to the RDP-TCP Listener
These play the vital part in allowing an RDP session to the server.
When a user is able to validate the above two conditions successfully, only then is the user provided with a successful RDP connection to the server.
The Remote Logon is governed by the “Allow Logon through Terminal Services” group policy. This is under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment.
By default, the Administrators and Remote Desktop Users groups are given remote logon rights. So, users who are a part of these groups will be authorized to logon remotely to the server.
Now, if you have a user account which is not a part of the Administrators or the Remote Desktop Users groups and you go ahead and add him to the GPO for “Allow Logon through Terminal Services”, they will still not be able to create a successful RDP connection to the server. The reason being that adding a user to this GPO only authorizes him for a Remote Logon to the server but does not give him the permissions to connect to the RDP-Listener.
Now comes into play the Logon privileges for the RDP-Listener. Once the user is authorized for remote logon his privileges to connect to the RDP-Listener is verified. If the user has permissions on the listener then the connection is successful. These permissions can be verified from RDP-TCP Listener properties.
When you look at the Permissions on the RDP-TCP Listener, you will see the below groups as shown below.
So that would explain how adding a user to “Remote Desktop Users” group allows them to create a successful connection to the server. Adding the user to the Remote Desktop users group gives them the “Remote Logon” Rights to machine as the Remote Desktop Users group is already a part of the GPO “Allow Logon through Terminal Services”.
“Logon” Privileges to RDP-Listener as this group is already added to the ACL list of the listener.
Permissions for the RDP-TCP listener can be set using the Tsconfig.msc console snap-in. You cannot modify the permissions on the RDP listener using group policy. This is why the best practice is always to add users or groups to the Remote Desktop Users group and not use your own group.
So to summarize, the GPO does authorize the user for a remote logon to the machine, but unless the user has permissions to the RDP-Listener he will not be able to RDP to the server. Hence it’s always a best practice to use the Remote Desktop users group to add the users to allow them to have RDP access to the server.
Domain controllers are an exception to this rule; the “Allow Logon through Terminal Services” does not include the Remote desktop Users group. This is because it is not considered a best practice to allow users to connect to sessions on a DC. If for some reason you do need to allow RDP access to a Domain Controller, you will have to add the group back in manually.
Depending on the missing rights or privileges, you might get various errors messages. Below are few common error messages that you may encounter.
When a user account is added to GPO and not a part of Remote Desktop group
When the user account is not given the Logon Remotely rights by GPO
When the user account is a part of the GPO but not in the Remote Desktop users group.
When user is part of the Remote Desktop users group but that group is not present in the GPO for “Allow Logon through Terminal Services”.
A few links that might be of interest in regards to this topic:
Default permissions for a local user account: http://msdn.microsoft.com/en-us/library/cc771990.aspx
Allow Logon through Terminal Services: http://technet.microsoft.com/en-us/library/cc758613(WS.10).aspx
Accessing Terminal Services Using New User Rights Options: http://support.microsoft.com/kb/278433
Description of Logon Rights and Privileges: http://technet.microsoft.com/en-us/library/bb457125.aspx
Hope this explains the relation between this group and GPO and also how to use them as required. Till next time…
Great article, infact many of times we also use the "REMOTE SETTINGS" tab on the my computer properties, but GPO should be there with the listener properties..
- Pankaj P.
This is killing me! I have set in my default GPO "Allow users to connect remotely using Terminal Services" and added the selected users to the "Remote Desktop Users" group. Also, I'm connecting via a TS gateway but as an administrator everything works fine (of course). I'm stuck at this point, ideas?
Thank you for your post btw!
You would need to isolate the issue first to see if the issue is happening if you using TS gateway or when you bypass it. A test would tell you if this is a problem with gateway configuraiton or RDS configuration issue.
So you can't just add a user to the built in group for Remote Desktop Users? Since the default logon privileges for domain member machines is Administrators and Remote Desktop Users, I fail to see how simply adding a user to that group and leaving the GPO default to 'Not Defined' still fails in having a user login remotely.
Very helpful and informative, thanks for the post
Great article! Thanks for the specific screen shots on what/where isn't set correctly.
Precise and simple! Thanks Much!
I am the builtin admin of a SBS 2011, when I want to remotely connect to that server I obtain "To log on to this remote computer, you must be granted the Allow log on through Terminal Services right .." I checked the RDP-Tcp listener properties as also the GPO but nothing wrong. I even added my account in the "Allow log on through Remote Desktop Services" but nothing has changed .. I have created another admin user through the console but same result .. I am quite a bit stucked at the moment where I type this message... Please help.
The paragraph about domain controllers not allowing Remote Desktop Users by default solved my problem for me. Thanks for that info!
I test it, with RemoteDesktopUser Group and all works fine. but I want to know how it work with GPO. It did not work! My missing information was the RDP Listener oO Sorry but there should be an info in the GPO Tab "explanation" about that :) Thanks for
the nice article!
Hi EdwinThank you so much for this article and for making life so easy, it is appreciated. Keep it up, thank you, thank you, thank you.Regards,Jojo Sond
Thanks so much for this. Cleared up some issues now that I can see the light
There is an issue where a standard user tries to logon to the console for troubleshooting (application). If the server is the member of a farm and the user is logged into another box it will not allow the user to connect to another server. This can be
quite irritating if the user doesn't understand these principles. To allow a standard user to log-in via the CONSOLE simply use this command:
wmic /node:localhost RDPERMISSIONS where TerminalName="Console" CALL AddAccount "domain\username$",1
Hope this helps someone!
Excellent article thankx - have a situation in Win Azure domain where newly created users have been assigned to groups domain users and rdt users but still receive the error message as above for “Allow Logon through Terminal Services” Any suggestions?
This doesn't seem to work if the DC is a Windows 2003 server and the client is a Windows 7 machine. Unfortunately, Microsoft broke a ton of things between the two when they release 7 and more when they released 8. Oh well. Thanks for the article.