If you are RDP’ing to a machine and you see:
The system administrator has limited the computers you can log on with.
the problem is the language Microsoft has used in their LOG ON TO button in Active Directory Users and Computers. It should be LOG ON FROM. If you restrict users access to log onto particular computers it also applies to the machines they are RDP’ing from.
For example USER-A has a Log On To setting on PC-A and PC-B. This means USER-A can log in from the desktop of PC-A or PC-B and they can RDP from PC-A to PC-B (or vise versa). What USER-A cannot do is sit at PC-C that is already logged in as another user and try to Remote Desktop to PC-A or PC-B.
The ‘fix’ is to add in the host name of the PC that the users will be logging in from. Soooo, in our example, if you USER-A will be sitting at PC-C (logged in as someone else) and wants to RDP to PC-A, you need to add PC-C (and make sure PC-A is there too) into the LOG IN TO in ADUC.
This has been a particular pain when trying to work with restrictions on Terminal Services / Remote Desktop Services servers.
It is a silly English language problem that I have argued with Microsoft Partner Support about a few times over the years.
This just caught me by surprise again and I spent more than an hour today fighting the problem after I change my PC to a new one running Windows 10.
This website uses cookies.
View Comments
Please explain what you mean with ".. into the LOG IN TO in ADUC". Where exactly is that located?
Hi Ika;
ADUC is Active Directory Users and Computers. ADUC used to be separate download called RSAT (Remote Server Administration Tools), but in Windows 10 is now just a feature you add:
Right click on the START MENU and select APPS AND FEATURES
Click OPTIONAL FEATURES
Click + ADD A FEATURE
type RSAT in the search and add what you want. Most likely RSAT: ACTIVE DIRECTORY DOMAN SERVICES AND LIGHWEIGHT DOMAIN SERVICE TOOLS
I hope that helps.
@HKI-JERRY: Thanks, I tried set and can remote to Server successful
This makes no sense. You say "you need to add PC-A into the LOG IN TO in ADUC." but above it PC-A is already added. Do you mean you need to add PC-C? I see why they disagreed with you. Your details are incorrect and don't make sense.
I can see the way you are reading this so we have clarified the text. Thanks for pointing out your perspective.
This solution worked for me!!! Thank you for posting this!!!
HKI-JERRY October 19, 2017 at 11:28 pm
I’ve been told that this is indeed identified as a bug. There will be a bugreport and my case will be linked to that. Also the case has been marked ‘free of charge’ which makes my Dutch heart happy ;).
There is also a workaround presented, however that does not fix the issue for my environment.
On the RDP server side set HKLMSYSTEMCurrentControlSetControlTerminal ServerWinstationsRDP-tcp “SecurityLayer”
Default is 1 (SSL). Set this to 0.
Investigation will still continue.
Below solutions worked for me :
1. On the client workstation, open the RDP file with Notepad and add the string enablecredsspsupport:i:0
I have tested this solution and its working fine
2. Add the source machine that the user is connecting to into the LogonTo field in Active directory
@Suman thank you! Step 1 is all I needed to fix my problem.
I've been told that this is indeed identified as a bug. There will be a bugreport and my case will be linked to that. Also the case has been marked 'free of charge' which makes my Dutch heart happy ;).
There is also a workaround presented, however that does not fix the issue for my environment.
On the RDP server side set HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-tcp "SecurityLayer"
Default is 1 (SSL). Set this to 0.
Investigation will still continue.
Actually, "Log On To" is the correct terminology, in older versions of Windows this describes the function accurately. In modern versions of Windows NLA is enabled by default for RDP.
This breaks the "Log On To" functionality in the way you describe. The reason for this is that the initial authentication is taking place *on the connecting computer*, not on the computer you're connecting to. Hence the reason that adding the connecting computer name to the list of Log On To workstations "fixes" the problem.
So it's not that the language is incorrect, it's that there is an incompatibility between the design of NLA and the design of "Log On To". The latter is a very old function and has not been updated to take into account the newer NLA functionality.
Will this change or be fixed in the future? Who knows. It's been this way for years (since NLA was introduced in Vista/Server 2008).
Thanks a lot!!!
Thanks Much!!!
Thanks for your post. I hope that Microsoft fix problem with new updates.