SOLVED: RDP The System Administrator Has Limited The Computers You Can Log On With – Log On To

If you are RDP’ing to a machine and you see:

The system administrator has limited the computers you can log on with.

RDP 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-A 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.

Comments

  1. Avatar
    John D July 19, 2018 at 2:15 pm

    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.

  2. Avatar
    Suman March 5, 2018 at 11:27 am

    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

  3. Avatar
    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 HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-tcp “SecurityLayer”
    Default is 1 (SSL). Set this to 0.

    Investigation will still continue.

  4. Avatar
    S August 30, 2017 at 2:48 am

    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).

  5. Avatar
    Harut August 23, 2017 at 5:36 am

    Thanks a lot!!!

  6. Avatar
    Raj August 14, 2017 at 6:20 am

    Thanks Much!!!

  7. Avatar
    Jose April 6, 2017 at 7:06 am

    Thanks for your post. I hope that Microsoft fix problem with new updates.

  8. Avatar
    Josh March 3, 2017 at 5:04 pm

    It looks like there’s a typo in your write up.

    “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-A into the LOG IN TO in ADUC.”

    If USER-A is sitting at PC-C and needs to RDP into PC-A, he would need to add PC-C into the LOG IN TO attribute, the first paragraph already stated that PC-A was in there.

Leave a Reply