Allow Logon Through Terminal Services vs. Remote Desktop Users group: Which and why?

I always end up forgetting which permissions I need to grant users and where to do so when setting up terminal services... so I go googling, and end up finding the answer eventually... but I figured it's about time I left a note for myself (and others!) about which permissions you need to grant users, where they are, and why.

For starters, this article does a great job of explaining:
http://blogs.technet.com/b/askperf/archive/2011/09/09/allow-logon-through-terminal-services-group-policy-and-remote-desktop-users-group.aspx

I'll do a quick summary of the contents, though, and borrow the images in case that site goes missing at some point. All credit goes to the original poster, of course. :P

First, there's the "Allow Logon Through Terminal Services" GPO, located under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\. This policy is what controls granting access to the particular machine. When you assign this GPO to a particular machine and add a group to it, that group automatically gains rights to log on to this computer, access local resources, etc. By default, Administrators and Remote Desktop Users are assigned to this policy.

Second, there's the Remote Desktop Users group. This group, as you saw above, is already a member of the "Allow Logon Through Terminal Services" security setting on most servers by default (except for domain controllers, I believe the default domain controller policy overrides this setting allowing only Domain Admins... but I could be wrong here.). The other thing this group does is grant access to connect to the RDP-TCP service on the server. You can see/change which users and groups have access to the RDP-TCP listener by opening the Terminal Services Configuration snap in and checking the Security tab, as shown below:



Finally, here's a quick recap of the typical error messages you see, and what that generally means:

1) "To log on to this remote computer, you must have Terminal Server User Access permissions on this computer..." or "The Requested session access is denied": This error means that the user that tried to connect has been assigned to the GPO correctly for "Allow Logon Through Terminal Services", but the user is not a member of the Remote Desktop Users group, or otherwise does not have permissions to the RDP-TCP listener on that machine. Go check the Terminal Services Configuration snap in.

2) "To log on to this remote computer, you must be granted the Allow Logon Through Terminal Services right..." or "The connection was denied because the user account is not authorized for remote logon." This error is pretty strait forward... the user is not assigned to the "Allow Logon Through Terminal Services" GPO.

Windows 7 Sharing Fix

There is nothing quite so humbling as bashing your head against a workstation for hours trying to figure out why the damn thing won't access a simple network share. Sure, there are a lot of specifics to the problem, but all the same... anyway, here's what I was up against:

- Two fresh windows 7 installations, all the latest updates (as of 2/23/2010)
- Workgroup machines, not in the same workgroup
- One has a Everyone share, with restricted NTFS permissions
- Neither machine can access eachother's c$ or admin$ shares

I am not sure which of the following steps fixed it... but I did all of them, and it's working now... so take that for what it is worth:

click the start button and type secpol.msc in the search function.

Browse to "Local Policies" -> "Security Options". Now look for the entry "Network Security: LAN Manager authentication level" and open it. Click on the dropdown menu and select "Send LM & NTLM - use NTLMv2 session security if negotiated". Apply the settings.

In the Advanced sharing settings page of Network and sharing center, you need to have it set as Work/Home profile. Try

-Enable network discovery
-Turn on file and print sharing
-Turn off password protected sharing
-Use user accounts and passwords to connect to other computers

The other settings such as encryption I have set as use 128 bit encryption.

Please check related policies.

1. Enter “gpedit.msc” in the Start Search box.
2. Open “Computer Configuration”/Windows Settings/Security Settings/Local Policies/Security Settings.
3. In the right pane, enable the following policies:

Network access: Allow anonymous SID/name translation
Network access: Let Everyone permissions apply to anonymous users

Also please disable the following policies.

Network access: Restrict anonymous access to Named Pipes and Shares
Network access: Do not allow anonymous enumeration of SAM accounts
Network access: Do not allow anonymous enumeration of SAM accounts and shares

Now, go into the control panel and search for homegroup. Click "Choose homegroup and sharing options" and remove yourself from any groups.

Reboot both machines.

Now, when you attempt to access a admin share, you should get a login box. Enter a username and password of an account present on the other machine, and you should get in.

Worth noting: if you attempt to browse to a share like \\workstation\share and double click on it, you may just get access denied. This is because Windows 7 is trying to use its local credentials to log into the share and failing. If you then attempt to log into an admin share, you will get a different error about connecting to one resource with more than one name.

Open a command prompt and type net use * /delete to remove all network connection sessions that are cached... then try to open the admin share by going to \\workstation\c$. It will ask you for a username and password, and that should work.

You can also create a mapped drive, and check the box telling Windows 7 you want to use different credentials. When you create the drive, it will ask for a username and password. Check the box to remember the password, then enter the local user name of an account on the machine which is sharing the folder you want to access (no domain or computer name in front of it... just username). Voila!