Link to home
Start Free TrialLog in
Avatar of YMartin
YMartin

asked on

2008R2 Terminal Server Access denied on Remote Control

When logged into the Terminal Server as administrator I am unable to remote control 2 user accounts.

RSOP on the TS shows "Set rules for remote control of RDS user sessions" as Enabled "Full Control without user's permission"

Session Host Configuration RDP properties, Remote Control tab is greyed out and lists the settings above.

When right clicking on the user in services manager and selecting "Remote Control" I am prompted to select the hot key and then after 1-2 seconds receive "Access Denied".

The users I am trying to remote control were removed from domain users and have very limited permissions.  Their sessions are locked down to exclude the control panel, cmd, shared folders, folder options and a few others.  However I put a test user in the same OU and in the same groups and I can remote control the session.  It is just those 2 users.

edit:
I just discovered It appears to be something to do with the RDP client.  If I use the user's credentials to log in from my machine it works.  I am told they are using windows 7 but will have to verify as that does not make sense.  Any ideas?
Avatar of zalazar
zalazar

When you check "Remote Desktop Session Host Configuration".
Get the properties of "RDP-Tcp" and click the tab Remote Control
Can you confirm that the settings are "Use remote control with the following settings"
Require user's permission: unchecked
Interact with the session.
Do you know if these settings are applied via a GPO ?

On the security tab
I assume that the Administrators group or a group where you a member of, has Full Control.

Can you maybe tell more about how you locked down the 2 users ?
Avatar of YMartin

ASKER

Thank you for the response.
The administrator account is listed as full control on the security tab.
Remote Control tab is greyed out due to the group policy but does show Remote control is activated, does not require the user's permissions and allows interaction with the session.

Here is the lock down:  
User Configuration (Enabled)hide
Policieshide
Administrative Templateshide
Policy definitions (ADMX files) retrieved from the local machine.Shared Foldershide
Policy Setting Comment 
Allow DFS roots to be published Disabled  
Allow shared folders to be published Disabled  

System/Ctrl+Alt+Del Optionshide
Policy Setting Comment 
Remove Task Manager Enabled  

Windows Components/Network Sharinghide
Policy Setting Comment 
Prevent users from sharing files within their profile. Enabled  

Windows Components/Windows Explorerhide
Policy Setting Comment 
Do not request alternate credentials Enabled  
Hides the Manage item on the Windows Explorer context menu Enabled  
No Computers Near Me in Network Locations Enabled  
No Entire Network in Network Locations Enabled  
Prevent access to drives from My Computer Disabled  
Remove "Map Network Drive" and "Disconnect Network Drive" Enabled  
Remove File menu from Windows Explorer Enabled  
Remove Hardware tab Enabled  
Remove Security tab Enabled  
Remove Shared Documents from My Computer Enabled  
Removes the Folder Options menu item from the Tools menu Enabled  

Open in new window


I don't think it is the restrictions because as I mentioned I have created a new user and applied the same security groups and the same restrictions and did not have the same issue.   It is something with those 2 user objects or their user profiles on the server.  I have checked the root permissions on the user profile folder but did not see anything wrong.
Thanks very much for the detailed info.
I have done some tests in a test environment but could also not find yet a settings that would cause this problem.
I have also tested with non-Windows RDP clients.
When using a Linux RDP client like freerdp or rdesktop, shadowing works without any problem.

You mentioned that it could be something with the profile.
If it's working from your computer with the user's credentials then it would not be logical that it's something related to the profile, e.g. some kind of user profile corruption.

Did you maybe already check the System and Application Eventlog for messages at the time the user logs in or when you try to shadow the session ?

Could you please check the security of the two AD user objects.
Is e.g. the AD group "Terminal Server License Servers" present with Read and Write Terminal Server license server or do you see any other differences compared to the other accounts.

What you might try is to download Process Monitor from Sysinternals and copy the executable to the terminal server.
https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx
Open 2 RDP sessions with Administrator permissions and a 3rd session with the user.
From the 1st RDP session start the Process Monitor.
From the 2nd RDP session try to shadow the user session and right after you get the error message stop the Capture within Process Monitor.
Then try to find something that is causing the issue.
You could try to set a filter like: Result |contains |denied |Include
Avatar of YMartin

ASKER

Excellent suggestions.  I will try this out.  Terminal Server License permissions are correct on those objects.  Give me some time and I will post back with what I find.  Thank you.
ASKER CERTIFIED SOLUTION
Avatar of Spike99
Spike99
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of YMartin

ASKER

That was indeed the issue.  They are using dual monitors.  That is why it was working fine with my connection but not theirs.  Thanks for the solution.
I am glad I was able to help!