I'm running a Windows Server 2003 PDC with AD and we have 2 machines that we require everyone to be able to remotely log in to. So I add "Domain Users" to the built in "Remote Desktop Users" account but after a policy refresh this group empties itself which results in the "The local policy of this system does not permit you to logon interactively" error.

In GPO I then added the "Domain Users" group to "Allow log on through Terminal Services". This gets me passed the previous error but brings up a new error message of "You Do Not Have Access to Logon to This Session".

Domain Admins can log on ok, it's just normal users that can't.

Anyone have any ideas? I'm tearing my hair out here. I come from a unix admin background so this is all new to me. GPO is proving to be a royal pain in the ass, but useful for some things.

Please help!


Edit: I should mention the 2 machines that I require people to be able to RDP into are Windows XP clients, so they don't have the "Terminal Services Configuration" tool. Edit2: Running Windows Server 2003 R2 x64, updated to the hilt.

  • Without GPO life would be a nightmare )) Jun 26, 2009 at 10:55
  • Life without Group Policy: Windows NT 4.0 domains... smile Give me "Startup Scripts" and I'd live without Group Policy. I wouldn't be happy, but I could make it work. Take away "Startup Scripts", though, and I'm going back to Xenix... (ick) Jun 26, 2009 at 11:00

3 Answers 3


In the first bit of your post it sounds like somebody had already configured a "Restricted Groups Policy" for the "Remote Desktop Users" group, which explains why it "emptied out". That's not a stock OS feature-- somebody configured that at some point. You got around it by either modifying the GPO that was "emptying out" the group, or by making a new GPO that applied after the existing "Restricted Groups"-containing GPO to override the setting.

The next bit-- the "You do not have access to logon to this session" bit is a bit more confusing. I've been trying to repro it on a Windows Server 2003 SP2 32-bit Std. machine for a bit now, and I can't come up with a repro condition.

If you would, open the "Terminal Services Configuration" tool on the machine, highlight the "Connections" node in the left pane, and bring up the "Properties" of the "RDP-Tcp" object in the right pane. Have a look at the "Permissions" tab and see that "Remote Desktop Users" is granted "User Access" and "Guest Access" (the stock permission).

Failing that, I'm not sure w/o being able to repro it. What service pack level are you running of W2K3?

(BTW: I've got a similiar background to you-- I started on Unix and moved over to Windows grudgingly. Group Policy is incredibly useful once you get over the quirks. I script Windows machines like a mad man because I can't stand to do the same work more than once. The built-in Windows command shell is utterly inferior to any Unix shell, but it can be coaxed into performing most tasks...)


Oh-- they're Windows XP machines. I didn't realize that. That changes things. I thought these were servers you were trying to access w/ RDP.

My psychic powers say that you're seeing the "You do not have access to logon to this session" message because there is someone already logged-on to the PC and the user logging-on with RDP doesn't have "Administrator" rights on the Windows XP machine. Windows XP can only host one RDP / console session at a time, and if someone is already logged-on only an "Administrator" user can remotely "bump them off" with RDP. All other users attempting to logon w/ RDP will receive the message you described above.

How does that look?

To investigate the "Restricted Groups" policy more, run the RSoP tool on the WinXP clients and see if there are any GPOs enforcing a "Restricted Groups" setting on "Remote Desktop Users". In a network I setup, for example, there would be. It's a common way to grant groups access to RDP on clients.

  • I am using Restricted Groups feature too. It is very funny when users add themselves to local admins, just to see that in a couple of minutes they disappear from admin group. Jun 26, 2009 at 11:00
  • I love "Restricted Groups". My only beef with it is that Microsoft din't include any kind of "additive" functionality-- i.e. a second restricted group policy for the same group in a later-appled GPO completely overrides the first one. I'd like to have an option where I can say "leave existing members intact, and just add this one". Oh, well-- nobody asked me. Jun 26, 2009 at 11:02
  • Hi Evan, thanks for your comment. Looking into the "restricted groups" thing now, and added some detail for clarity in regards to the targeted RDP machines (them being Windows XP clients).
    – djk
    Jun 26, 2009 at 12:58
  • Have a look at my edit. I believe I've zeroed-in on your issue. Jun 26, 2009 at 13:52
  • No one was logged in to the machines so I knew it wasn't that problem, it wasn't saying "Domain\User is connected they have to log off first", well, you know what it says. I checked the GPO and in "Restricted Groups" there was indeed the RDP Users group and it was empty. Added in Domain Users and will test soon. Currently the 2 boxes are being used (development purposes). Will report back but I think the "Restricted Group" was the problem! Thanks for all your help.
    – djk
    Jun 26, 2009 at 15:29

Well, I also believe it is Restricted Groups, causing such a behavior. GPOs are really great to use, that's one of my most beloved features. To make your life MUCH easier there is a tool, called Group Policy Management Console - if you don't use it yet, just start now!

The next tip is to use Policy Modelling and Resultant sets of policies to see a very detailed view of what is applied to the machines and users. You can do it in GPMC. I think that Restricted Groups are applied on rather high, maybe domain level - and that is ok to leave so. Instead of rewriting this policy, you'd better do the following:

1) Make a special OU, for example "Terminal Servers" or "RDP Enabled" and place the needed computer accounts in it.

2) Create new policy called "Place Everyone to Remote Users Group" or smth like that, edit Restricted Groups section in it.

3) Link it t your newly created OU.

4) Check if that works :)

5) Use GPMC to investigate how GPOs are applied and in what order. By the way, GPO linked to lower-level OU would have HIGHER priority, then GPO, linked to parent OU or domain level.

  • 1
    brianmadden.com/blogs/brianmadden/archive/2005/12/28/… - here is a very nice book, a must-read for anybody, administering Terminal Services.
    – Speedimon
    Jun 26, 2009 at 13:10
  • I'll be sure to check this out, thanks speedimon. When my users go home I'll be doing testing.
    – djk
    Jun 26, 2009 at 15:47
  • 1
    I think that trying to talk about GPOs with "priority" is just confusing. It's much easier, to my mind, to just learn the algorithm that Group Policy uses to build the list of GPOs that apply to a user or computer (and how "Block Inheritance" and "No Override" cause changes in that algorithm). I've seen too many AD admins who have no idea how group policy actually works, and that's disappointing. It's such a great feature, and the policy application order is a very simple algorithm. Jun 26, 2009 at 16:41

I've been having this same problem. I have an XP and a Vista computer I'm trying to grant RDP privileges to a specific user group. Eventually, I gave up trying to use group policy and had to go to each computer's Control Panel → System → Remote tab → "Select Remote Users" and add the group there. Apparently "Allow log on through Terminal Services" doesn't do what it sounds like (at least not on workstations).

I would rather do this through group policy also, so do post an answer if you find a way to do it!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.