How to grant ‘Allow log on through Terminal Services Right’

Warning
This blog post is included for archival purposes and may contain outdated information. While it provides historical insights, we strongly recommend that you double-check the details before relying on any of the information outlined here.

To log on to this remote computer, you must be granted the Allow log on through Terminal Services right. By default, members of the Remote Destop Users group have this right. If you are not a member of the Remote Desktop Users group or another group that has this right, or if the Remote Desktop User group does not have ths right, you must be granted this right manually.

We were setting up remote access for a user on a domain controller for some tests. This user was not an admin (but belonged to the Remote Desktop Users) and kept getting the same error message above. Setting this user to domain admin solved the problem, but of course I did not want to make any remote user a domain admin.

It so happens that it is not enough for a user to belongs to the Remote Desktop Users to gain the rights it needs. Here is how you fix this:

  1. Open gpedit.msc (the local group policy editor)
  2. Expand Local Computer Policy –> Computer Configuration –> Windows Settings –> Security Settings –> Local Policies –> User Rights Management
  3. Look for the setting on the right called Allow log on through Remote Desktop Services
  4. Double click this policy
  5. Add the user/group you would like to have remote access to the box.

Once this was done, the user was able to connect w/o hassles.

*That* pesky setting

 

About Author

Christian Saborio

Christian is a seasoned computer engineer with a rich career spanning collaborations with industry leaders such as Artinsoft (now Mobilize.net), Microsoft, HP, and Intel. As a technical evangelist and trainer, Christian honed his expertise in Costa Rica and Seattle, delivering impactful solutions and sharing his knowledge.

Now based in Sydney, Australia, Christian channels his passion into web development, leading a talented team to tackle diverse projects with innovation and precision. His commitment to crafting exceptional digital experiences reflects his deep-rooted enthusiasm for technology and problem-solving.

Comments

  1. negrofeo says:

    Muchas gracias por la información la verdad es que fue de gran ayuda.

  2. Jake says:

    Thanks Christian, worked like a champ!

  3. mrbrown says:

    This worked! after only an hour trying to figure it out with other sites. thank you

  4. mendy says:

    worked for me too. thanks!

  5. Hussain says:

    Thanks, wonderful post

  6. Praful Soni says:

    What if it’s grayed out? I’ve logged on (remotely) with local admin and domain admin and still can’t access it. Do you have to set this while physically at the station?

    • Christian says:

      All the work I was doing back was done connecting remotely to the machine or using remote management, I doubt that’s the reason why you are seeing it greyed out. Maybe some other policy is affecting what you can see/change?

      • soni says:

        Grayed out means I am not able to click on “add user/group” button (its disabled).

        I logged in using VNC Viewer as local as well as domain administrator but result is same.

  7. Umair says:

    Great!

  8. Marco says:

    It works correctly, thanks a lot

  9. G.Ashraf Ali says:

    Thanks , this is what i looking for.

  10. SeismicMike says:

    Thanks for this tutorial. Bookmarked. I know I’ll be back here. I love how Windows says “By default, the Remote Desktop Users group has this right” when it doesn’t. Typical Redmond, I guess =/

  11. Sherri says:

    What if it’s grayed out? I’ve logged on (remotely) with local admin and domain admin and still can’t access it. Do you have to set this while physically at the station?

  12. Nige says:

    Any thoughts why my option to change who can access to the server is greyed out. Cannot add or remove name or groups

  13. Cole says:

    Perfect!! Thank you! I was Googling for hours before I found this. 30 seconds to fix 😉

  14. laxman says:

    nice thank you very much for info

  15. Jon says:

    Thanks, tried many other group policy settings, but this one finally fixed the problem!

  16. Dirk says:

    Still doesnt work. Trying to get RDS to work- and nothing.

  17. Richard says:

    Perfect – thank you!

  18. Gary Ramos says:

    thank you very much for this info

  19. Dan Erbs says:

    Thanks ,it worked

  20. Tim Fiandola says:

    THANK YOU!!!!

  21. Charith says:

    it’s working thanks…….

  22. eric says:

    Thank you so much, it worked like magic. It was driving me crazy for a while

  23. Peter says:

    Way to go! It worked perfectly 🙂

  24. Tim says:

    Fantastic info, I search for ages in technet and could not come close to this answer, I thought I was going to go insane. Thanks for the info it works great. i did add the Remote Desktop Users Group and not induvidual users and that method works a treat too.

  25. MassiveLoop says:

    When a server has the Domain Controller role added, by default, the server deactivates the ability for anyone(including Remote DT Users) to access it remotely except of course Admins. That is why this step is needed at the local(server OS) level as opposed to the global user level.
    The reason for the server to default to this is because of the over-privileged access one may obtain to network resources.
    Great post! I know this will help many new small net Admins.
    As a side note, having an all-in-one server is good for practicing and SOHO LANs but once you get to the enterprise level its a good idea to keep your domain controller separate from your terminal server(remote DT). This will reduce the possibility of malicious network wide attacks.

  26. Anil says:

    But where we have to follow this steps ?…is it on local client system or on Domain controller. and why does it happens to particular member while even other users having same right and same access…they dont required Domain Admin rights to take a remote of particular server.

  27. geeth says:

    Thank you so much. almost you saved my job.

  28. Farhan says:

    Thanks mate! saved my time as well.. 🙂

  29. Manny Pacquio says:

    U r the man!

  30. Kevin says:

    The reason you wouldn’t want to put the Remote Desktop Users group into the policy is because they’re designed to control two different things. If you want an entire group to have remote login access create a new group, put everyone you want in there, and add that group to the policy.

  31. barun says:

    Thanks it is very help full to me,

  32. sandeep says:

    Thanks!

  33. mercy says:

    Thanks so much, the information saved me and my colleague much time to figure out

  34. Peter says:

    Thanks. this post is a savior!!

  35. kejjer says:

    Thanks–I have to say I install servers about once month now –but I always struggle with this part and have to google it when dealing with TS on the domain controllers.
    Thanks so much–your page is the best I have found in the last several years.

  36. Ashish Mishra says:

    Thx ton this is desired solution.

  37. amin says:

    YOU ARE AWESOME

  38. Jodie says:

    Thanks a lot 🙂

  39. Ajay says:

    Thanks!

  40. John Jayaseelan says:

    Thanks a lot, You saved my day 🙂

  41. Ricardo says:

    Excellent! That solved the problem I had. Thanks for offering such a clean and direct solution.

  42. jalel says:

    thank you very much !!!
    but why do we have to use gpo ?
    it has to work when users belong to Remote Desktop Users group !!

  43. Jeevan says:

    Thanks it works.

  44. Stefan in Sweden says:

    Thanks

  45. Edwin says:

    Thanks! It really saves me.

  46. George says:

    Thanks so much for this solution. Fixed the issues right away.

  47. Steve0 says:

    Thanks!

  48. Marvin says:

    YOU ARE AWESOME!!! It worked!

  49. Aadithya says:

    This helped me too! Great! Thanks!!!

  50. Bill says:

    The Remote Desktop Users group controls who can connect. The security policy controls who can login once they are connected. Two different things.

  51. André says:

    Obrigado !

  52. Izhar Saharuddin says:

    Thank you. You have saved me a lot of time on this.

  53. Dan says:

    Legend – this has been making my head hurt for days!

  54. Warren says:

    While you are in the Group Policy editor, why not add the group “Remote Desktop users” to that list, and then just put people into that group when they need to get access to the server remotely?
    I find it easier to add people to a group than to go into gpedit every time.
    Just a thought.

  55. Carl says:

    Wow, thanks. Had this issue for a while and finally Googled it again.
    This worked!!
    So many other tops hits misses the boat entirely.
    I appreciate your help.

  56. Heidi says:

    Thnx for this solution!! Really helped me out!

  57. josh says:

    Thank you!

  58. Alitet says:

    THANX!!! What’s for Remote Desktop Users group then? MS like a lovely wife. You hate her but you can not live without her.

  59. Mirbek says:

    Thank you so much! I was pulling off my hair until I found this.

  60. Richard says:

    Must be more to it, I have 7 users and all can access through Remote Desktop except 1
    I did verified this and still have 1 that cannot connect?

  61. Troy says:

    Thank you, thank you, and thank you!

  62. Harry says:

    Thanks. That helped.

  63. Tony says:

    Thanks for this info. It helped a lot!

  64. Zevargo says:

    Thank you.

  65. Zevargo says:

    Thank you. Just what I was searching for.

  66. Patrick says:

    Wow! That’s exactly what I’m looking for!

  67. Mike Breslin says:

    Thanks! This really saved me.

  68. Art says:

    Thanks a BUNCH ! ! ! ! Exactly what I was looking for….

  69. Robert says:

    thx, it was my salvation!

  70. Mike says:

    Thanks, exactly what I was looking for!

  71. Rick says:

    Thanks for this! It was driving me nuts trying to figure it out!

  72. Peter Saunders says:

    Worked a treat – thanks.

Comments are closed

Your one-stop shop for professional, lightning-fast websites.
ScorpioTek, based in Sydney, Australia, is a seasoned web development firm with a proven track record of delivering cutting-edge, user-friendly websites for a diverse range of clients.
Let's Talk
Nougat Chatting
Thank you for your interest. Please fill out this form to provide us with your contact information. We'll get back to you as soon as possible.