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


14 Comments

Ika · November 27, 2020 at 6:44 am

Please explain what you mean with “.. into the LOG IN TO in ADUC”. Where exactly is that located?

    Ian Matthews · November 27, 2020 at 4:12 pm

    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.

Haiclassic Haiclassic · March 31, 2020 at 3:01 am

@HKI-JERRY: Thanks, I tried set and can remote to Server successful

bobsmith · March 26, 2020 at 9:43 am

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.

    Ian Matthews · March 26, 2020 at 11:49 am

    I can see the way you are reading this so we have clarified the text. Thanks for pointing out your perspective.

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.

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

    Pete · January 11, 2023 at 3:19 pm

    @Suman thank you! Step 1 is all I needed to fix my problem.

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.

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

Harut · August 23, 2017 at 5:36 am

Thanks a lot!!!

Raj · August 14, 2017 at 6:20 am

Thanks Much!!!

Jose · April 6, 2017 at 7:06 am

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

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

Avatar placeholder

Your email address will not be published. Required fields are marked *