none
Remote Desktop denies login

    Question

  • Hi all,

    I recently upgraded a client from Windows 7 to Windows 8.1 (let's call it CLIENT_X). The computer is member of a domain.
    In this domain, there is a user (let's call him RESTRICTEDUSER), which is a member of the default group Domain-Users.
    The user is allowed to login only on the machine CLIENT_X by the "logon to" property in AD Users & Computers.

    Before the upgrade, I was able to connect to the CLIENT_X using the username RESTRICTEDUSER and appropriate password from another machine (where I was logged in using another username):

    CLIENT_A (User Admin) --> Remotedesktop --> CLIENT_X (User RESTRICTEDUSER)

    Now, after the upgrade to Windows 8.1, I get the following error message from remote desktop:

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

    When I add the machine I am connecting from (CLIENT_A) to the list of machines where RESTRICTEDUSER is allowed to logon to, the connection works. Of course, the user is then also able to logon directly to CLIENT_A, which is not intended.

    Therefore, I am asking for help, how to restore the old behaviour.

    Tuesday, November 19, 2013 8:16 PM

All replies

  • Hi,

    Sorry for my dilatory reply, From the error"The system administrator has limited the computers you can log on with", it indicates that the problem caused by the permission of the computer you log on with, CLIENT_A. Say in other words, you couldn't log to CLIENT_X from CLIENT_A though RDP.

    Firstly, I would like to suggest you follow the steps below to make a test.

    1. Try to use different computer to remote CLIENT_X though RESTRICTEDUSER for test.

    2. Try to use other user account log on to CLIENT_X from CLIENT_A.

    Though the test above, may be we can find the root cause of this problem.

    Secondly, please check CLIENT_X RDP properties, make sure the user RESTRICTEDUSER is in the list.

    Thirdly, this problem also can be caused by RDP version compatibility, please check and upgrade RDP Client to be latest for test.


    Roger Lu
    TechNet Community Support

    Monday, November 25, 2013 2:39 AM
    Moderator
  • Hi,

    Sorry for my dilatory reply, From the error"The system administrator has limited the computers you can log on with", it indicates that the problem caused by the permission of the computer you log on with, CLIENT_A. Say in other words, you couldn't log to CLIENT_X from CLIENT_A though RDP.

    Firstly, I would like to suggest you follow the steps below to make a test.

    1. Try to use different computer to remote CLIENT_X though RESTRICTEDUSER for test.

    2. Try to use other user account log on to CLIENT_X from CLIENT_A.

    Though the test above, may be we can find the root cause of this problem.

    Secondly, please check CLIENT_X RDP properties, make sure the user RESTRICTEDUSER is in the list.

    Thirdly, this problem also can be caused by RDP version compatibility, please check and upgrade RDP Client to be latest for test.


    Roger Lu
    TechNet Community Support

    Hi, thanks for your reply..

    To answer your suggestions:

    1.  I tried logging in via rdp from different machines, the problem is the same.

    2.  Other user accounts work fine, i can connect to CLIENT_X using other (administrator) accounts. There is only a problem with the user(s) that are restricted to logon ONLY on CLIENT_X and nowhere else.

    Both computers are running Windows 8.1, so there should not be any version incompatibilites.
    The user is explicitly in the list of allowed RDP-users.

    To clarify; Locally on CLIENT_X, I can logon using the RESTRICTEDUSER account.

    Is there even a way of restricting logon FROM specific machines, as the error message indicates?
    I am not aware of such a mechanism in group policy, that's why I'm asking.

    all the best

    - schalli

    Wednesday, November 27, 2013 9:56 PM
  • Hello,

    I am also having the same when logging into Windows 2012 R2 servers from Windows 8.1. Windows 7 behaves. We use the "log on to" permission feature in active directory to control which servers and computers users can log into. This works fine until  Server 2012 r2. Add the server name as per normal and "The system administrator has limited the computers you can log on with" continues. Allow the user log on to access to all computers and it works. Can anyone from from Microsoft confirm the behavior and whether its a bug or a change?


    • Edited by largechicken Thursday, November 28, 2013 10:06 PM
    Thursday, November 28, 2013 10:06 PM
  • I tried logging on to the CLIENT_X from different platforms using the username RESTRICTEDUSER. Here is the result:

    Windows 7 and Windows Server 2008 R2 give the error message "The Local Security Authority cannot be contacted.", although the password is set to never expire.

    Windows 8.1 returns the already known "The system administrator has limited the computers you can log on with.".


    Monday, December 2, 2013 2:32 PM
  • Can someone from Microsoft confirm the problem and tell us, whether this is a bug or a new, undocumented feature?
    Wednesday, December 11, 2013 1:35 PM
  • I am having the same issue and I have been doing some testing of my own.

    If I set account restrictions (log on to) for a specific user (because I want him to log on only to certain servers and not others), from Windows 8.1, I am getting error message: the system administrator has limited the computers you can log on with.

    The only way I have found to bypass this issue is to include in the "log on to" section the name(s) of the computer(s) "from which" the user is allowed to log on.

    Of course, this behavior doesn't exist in Windows 7 or Vista on the client side and does not exist if Remote Desktop server is Windows 2008 R2. Only the combination of Windows 8.1/Windows Server 2012 R2 is having issues.

    As far as I am concerned, I cannot go to production with this issue since a user may log on from several computers to a limited number of servers. The goal is to limit where a user can log on, not from where he logs on.


    Benjilafouine

    Wednesday, March 12, 2014 6:00 PM
  • Hello, I have the same problem with our terminal server farm 2012R2 and Windows 8.1 clients. 

    Is there already a solution? 

    Greeting Hubert

    Thursday, April 10, 2014 3:55 AM
  • Could any body try with Windows 8.1 Update 1 ?

    Rolando Ramirez G.

    Tuesday, April 15, 2014 8:29 PM
  • Could any body try with Windows 8.1 Update 1 ?

    Rolando Ramirez G.

    I upgraded both systems (remote desktop host and client) to Windows 8.1 Update 1, and the error still remains the same.
    Tuesday, April 15, 2014 8:34 PM
  • There is another thread on this, but no solution:

    http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/Windows_Server_2012/Q_28386816.html

    Tuesday, May 6, 2014 10:34 AM
  • Having the exact same issue. Any updates or news with regards to this? Thanks.
    Monday, June 2, 2014 10:32 AM
  • For the time being, I have decided to use the following approach: http://4sysops.com/archives/deny-and-allow-workstation-logons-with-group-policy/
    Monday, June 2, 2014 10:36 AM
  • This question is NOT answered. This is a clear bug!

    Problem: Windows is applying log on rules defined for the TARGET computer to the SOURCE computer.

    • Edited by AnguelS Tuesday, July 8, 2014 12:30 PM
    Tuesday, July 8, 2014 12:14 PM
  • I got the same issue as well. A lot of other sites state that it is an error on both Windows 8 and Windows Server 2012. 

    The only workaround that I found to have worked would be creating a GPO for the computers to restrict or allow access to a security group.

    How I did it was, create the relevant security groups for the users you would either like to restrict or allow and another group for the computers. Create a new GPO in the GPM and in the Security Filter you add the computer security group. In the GPO you go to Computer Configurations > Policies > Windows Settings > Security Settings > Local Policies/User's Rights Assignment. Then change the services either: Deny log on through Terminal Services or Allow log on through Terminal Services (depending on if you want to deny or allow) select define these policies and then add the user's security group. Click Apply, then enforced the rule. Restart the computer and then it should resolve the issue.

    I had to also remove the computers on the user's profile on they can log on to for it to work also.

    Wednesday, July 16, 2014 3:29 PM
  • How about Microsoft finally fixing this stupid bug? Nobody seems to care there....
    • Proposed as answer by Janakaravi Monday, June 20, 2016 8:12 AM
    Monday, July 21, 2014 8:50 AM
  • Hi, schalli

    One of our servers is running Windows Server 2012 R2 and having exactly same issue. Although I don't have a exact solution for you, I have been using another workaround (sort of).

    Basically I used an administrative login, which has remote access to many servers (so no log on restrictions), to log onto this server first. Then I can use task manager users section to connect to the other login (which has log on restriction).

    Obviously this requires the restricted account is already logged in that server, which it is always the case in our situation and can also be done through vsphere console.

    Hope this helps.

    Ben at Tassie

    Tuesday, July 29, 2014 2:18 AM
  • Hi

    We have same problem. I'm trying to restrict outsourced VPN users to which server can login and this "Log on to..." clearly doesn't work as it should.

    Any news on this issue? Did someone report this to MS?

    We have Windows 2012 R2 domain controllers.

    Clients are Windows 8.1 and Windows 7 and both have same problem.

    Friday, September 5, 2014 1:21 PM
  • Hi All,

    I'm creating a case at this moment. I will add this discussion to the URL's

    Kind regards,
    Marcel

    Thursday, September 11, 2014 11:51 AM
  • Great, thank you!

    Will you please keep us posted about Microsofts reaction to you case?

    Thursday, September 11, 2014 11:55 AM
  • I noticed an issue with the RDP files from Azure to connect to a given virtual machine

    if I moved the file from my download folder to my desktop and tried to open it, it balked

    so I changed my download folder to the desktop, and then downloaded it again and it work

    seems that moving the RDP file has some security mode attached to it, likely to prevent it from being copied by malware etc. I have looked at this briefly, but there are lot of posts says Google


    Corsair Carbide 300R with TX850V2
    Asus M5A99FX PRO R2.0 CFX/SLI
    AMD Phenom II 965 C3 Black Edition @ 4.0 GHz
    G.SKILL RipjawsX DDR3-2133 8 GB
    EVGA GTX 660 Ti FTW Signature 2 (GK104 Kepler)
    Asus PA238QR IPS LED HDMI DP 1080p
    ST2000DM001 & Windows 8.1 Professional x64
    Microsoft Wireless Desktop 2000 & Wacom Bamboo CHT470M

    Place your rig specifics into your signature like I have, makes it 100x easier to understand!

    Hardcore Games Legendary is the Only Way to Play!

    Thursday, September 11, 2014 12:08 PM
  • Hi,

    could you specify "balked"? What happened exactly? Did you get the same error message as we did, i.e. "The system administrator has limited the computers you can log on with [..]"?

    Thursday, September 11, 2014 12:12 PM
  • Hi,

    could you specify "balked"? What happened exactly? Did you get the same error message as we did, i.e. "The system administrator has limited the computers you can log on with [..]"?

    my credentials were refused


    Corsair Carbide 300R with TX850V2
    Asus M5A99FX PRO R2.0 CFX/SLI
    AMD Phenom II 965 C3 Black Edition @ 4.0 GHz
    G.SKILL RipjawsX DDR3-2133 8 GB
    EVGA GTX 660 Ti FTW Signature 2 (GK104 Kepler)
    Asus PA238QR IPS LED HDMI DP 1080p
    ST2000DM001 & Windows 8.1 Professional x64
    Microsoft Wireless Desktop 2000 & Wacom Bamboo CHT470M

    Place your rig specifics into your signature like I have, makes it 100x easier to understand!

    Hardcore Games Legendary is the Only Way to Play!

    Thursday, September 11, 2014 12:16 PM
  • Hi Vegan Fanatic,

    I think you are mixing another issue into this thread. We are talking about on-premise solutions. It has nothing to do with .rdp files. I for one am using mstsc.exe and just configure the connection manually. Also there are no TS Gateways anywhere in my environment. As schalli asked, Did you receive the following error?:

    "The system administrator has limited the computers you can log on with. Try logging on at a different computer. If the problem continues, contact your system administrator or technical support."

    Or something else?

    Kind regards,

    Marcel

    Thursday, September 11, 2014 1:02 PM
  • Will do that. Create a B case so I should be contacted in 1,5 hour from now.

    Kind Regards,
    Marcel

    Thursday, September 11, 2014 1:03 PM
  • The OP did not make that clear, and this is the only issue I have encountered with remote desktop

    using a local server etc, I have not experienced problems

    if you are not using an administrator account, you will have to fiddle with policies


    Corsair Carbide 300R with TX850V2
    Asus M5A99FX PRO R2.0 CFX/SLI
    AMD Phenom II 965 C3 Black Edition @ 4.0 GHz
    G.SKILL RipjawsX DDR3-2133 8 GB
    EVGA GTX 660 Ti FTW Signature 2 (GK104 Kepler)
    Asus PA238QR IPS LED HDMI DP 1080p
    ST2000DM001 & Windows 8.1 Professional x64
    Microsoft Wireless Desktop 2000 & Wacom Bamboo CHT470M

    Place your rig specifics into your signature like I have, makes it 100x easier to understand!

    Hardcore Games Legendary is the Only Way to Play!

    Thursday, September 11, 2014 1:04 PM
  • All,

    From http://mobile.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/Windows_Server_2012/Q_28386816.html I found another workaround than the one I am using right now (Allow logons from all computers). It seems that if you add the source server (where MSTSC.exe is run from) to the LogonTo attribute you can connect. This is working in my environment. This is a bad solution which is imho not in line with wat the attribute should do. You should be able to log on to the server stated without checking the source for this access. Our users log on with a desktop account on the Terminal Server and use admin credentials to connect to an application server for management.

    Our TS's are quite elastic so we cannot use some sort of scanner which checks every admin accounts LogonTo attribute if there is a new TS which may be used to launch connections. Also I see VPN as a use case in this thread. This van come from any computer in the world, we cannot add all those names to the LogonTo attribute, 8192 limit for one ;)

    Kind regards,
    Marcel

    Thursday, September 11, 2014 1:11 PM
  • All,

    Just got contacted by a Dutch Support Engineer (which is no problem, I'm dutch too) and explained the situation. He said it was a clear story and he will start investigating. Just waiting for the scope agreement...

    Cheers,
    Marcel


    Windows Server 2012 R2, Windows Server 2008 R2, Citrix XenApp 7.5, Citrix XenApp 6.5 || PowerShell

    Thursday, September 11, 2014 1:47 PM
  • Marcel excellent!, i hope they fix this nasty bug by next month patch schedule :)
    • Edited by ilukeberry Friday, September 12, 2014 1:23 PM
    Friday, September 12, 2014 1:23 PM
  • All,

    At the moment Microsoft seems to be moving into the 'This behavior is by design' corner of the playing field. I'm still asking questions as to find what decision has made the LogonTo field also needs to be populated with the clients name.

    Can you guys please give me use cases where this behavior is unwanted? I have:
     - External Consultant connecting over RDP to a server from his own laptop.
     - Using seperate desktop and administrative accounts.

    I also tested the RDP connection with and without NLA, this made no difference on Win2012R2.

    Kind regards,
    Marcel


    Windows Server 2012 R2, Windows Server 2008 R2, Citrix XenApp 7.5, Citrix XenApp 6.5 || PowerShell

    Friday, September 12, 2014 2:04 PM
  • Hi, thank you for reporting, it would be awesome having it fixed.

    My use case is the following:

    We have several virtual servers, where only a restricted group of users should login to.

    Users are logging in to these machines using a username that is NOT the same as the one they logged on to the machine locally.

    They are not allowed to logon locally on any other system. This has to do with security issues and access restrictions.

    In the past, this worked great by setting "LogonTo" accordingly.

    Anyway, iff we have to include the source machine into the LogonTo list, it undermines the approach to restrict users to certain systems.



    It might be possible to use a workaround here, but what would be the use of LogonTo now?

    Besides, that change in behaviour was never documented..

    Friday, September 12, 2014 2:14 PM
  • If you want my opinion, this is not by design. It makes absolutely no sense. Clearly a bug.

    Benjilafouine

    Friday, September 12, 2014 2:19 PM
  • All,

    Just a quick update. The case has been escalated internally by Microsoft. The Escalation Engineer has been able to reproduce the behavior. Logfiles have been created and are being analyzed. I hope to get a definitive answer within a few days. I will keep you guys posted.

    Cheers Marcel


    Windows Server 2012 R2, Windows Server 2008 R2, Citrix XenApp 7.5, Citrix XenApp 6.5 || PowerShell

    Thursday, September 18, 2014 1:15 PM
  • Hi Marcel,

    Is anything new in this case.

    Thx Pete

    Tuesday, October 21, 2014 8:56 AM
  • Hi Pete and others,

    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.

    Kind regards,
    Marcel


    Windows Server 2012 R2, Windows Server 2008 R2, Citrix XenApp 7.5, Citrix XenApp 6.5 || PowerShell

    Thursday, October 23, 2014 7:50 AM
  • AWESOME!!!! :) i hope they will fix this and patch it ASAP :)
    Monday, October 27, 2014 2:36 PM
  • This is really starting to annoy me as we bring more Windows 8 machines on line.

    Has anyone had an update on when Microsoft might get around to fixing the issue

    Friday, January 23, 2015 6:18 AM
  • I haven't finalized my testing but was able to reproduce this on my win 8.1 PC RDP into 2012R2 inside my domain. I added the server to the list of computers I can log on to and got the exact error message. I went and added the pc to the list  I am using to RDP to the server and bang was able to log on.   I just need to test external VPN users now
    Thursday, February 5, 2015 7:07 PM
  • You gotta love Microsoft... read this...
    I had this problem. Used MSDN support. After 9 weeks they told me "it is a bug, but we don't have the resources to fix it". They told me "maybe MS premier support can do something for you" Me: "how much" - MSDN: "15,000 euros per year at least" - Me "*gulp*"
    So I asked a befriended admin who happens to have a premier support contract to have them work on it... after (you gessed right) another 9 weeks, MS told me: "this is expected behavior, it is by design". To quote the engineers:

    The RDP client behaviour is changed in 8.1 and it now it enforces NLA which uses CREDSSP – it is more secure. 

    Previous behaviour is that it allowed fallback to “no NLA” when NLA failed.

    If NLA is set to “required” on the RDP server side then it is expected that the client connection will fail due to the workstation not being in the list. NLA is using Kerberos or NTLM authentication which cares about where you log on from as per above attribute. In addition if you take RDP out of the loop and browse to a share, for example, on the same RDP server from any OS workstation which is not in the <log onto> list it will also fail with the same error STATUS_INVALID_WORKSTATION!. 

    Available options here:

    1. Use this setting: HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-tcp "SecurityLayer", Default is 1 (SSL).  -> Set this to 0.


    2. On the client workstation, open the RDP file with Notepad and add the string enablecredsspsupport:i:0

    3. Add the source server that the user is connecting to into the LogonTo field.

    Ain't that cute? So it's been no bug all the way. Win7 and Server 2008R2 are the systems with buggy/insecure behavior... LOOL. So I had him tell them the following: "Dear Support,
    thank you, it seems there is no easy way out. Either we reduce the security one way or the other.
    Let's recapitulate: After all this time you found out, it's expected behavior and call it more secure than with previous versions.
    I see the point, but for the use case of users remoting in to our terminalserver ("TS") from different workstations at a remote location/remote company that we don't know the name of, this is actually less secure than before.
    Why do I see it this way? Because the check that is performed (->may the user log on from this workstation?) can be easily overcome. The check just looks at the name of the machine, not even does that machine need to be a member of our domain. So if someone knows, he can easily overcome that check by renaming his machine to an already allowed machine so that restriction is pretty useless in this case. It cannot be used to limit the user to use a set of known machines to connect *from* as we don't even know those machines in the first place, they are not members of our domain but of a remote domain, another company. They logon to their machines using User A and logon to ours using user B, only B is a member of our domain.There isn't and never will be a domain trust.

    So instead of using your proposed workarounds of which 1 and 2 reduce the security and 3 is not possible since we do not know the names of the machines that will be used in the future (but we only know the username), we will stick with our workaround and allow that users' accounts to logon anywhere (which is most undesirable!). To get back some security, we applied policies that disallow the logon to any system but the TS via GPO. And we applied firewall policies at the TS that won't let him get anywhere.

    Conclusion: The "workstations allowed" list has its use case: limiting it, you can keep people away from logging on *to* machines so they cannot influence or spy on these systems. However, from what we have here, from the perspective of a TS, limiting what machines a user can connect *from* is not beneficial for security, in the end, quite the contrary is the case. Do me a favor and reconsider!"

    They have not answered so far. maybe in another 9 weeks, maybe never? My guess is "never".

    Wednesday, February 11, 2015 11:50 PM
  • I have news for you. Yesterday, I already  wrote a huge text. After submitting it, it read "your contribution is being reviewed" - for whatever reason...it did never appear although I can see it in my activity list...

    That's why I'll keep it short and sweet this time.

    Folks, this is by design. MS premier support told me that after weeks of reviewing the problem. I know it makes no sense at all, but it is how network level authentication is supposed to work after they enhanced it in win8.x/2012.

    --

    Let's see if this contribution get's listed. If so, I'll add more.

    Thursday, February 12, 2015 11:15 PM
  • Ok, it got listed. Then I'll add what MS premier support had to say:


    The RDP client behaviour is changed in 8.1 and it now it enforces NLA which uses CREDSSP – it is more secure. 
    Previous behaviour is that it allowed fallback to “no NLA” when NLA failed.
    If NLA is set to “required” on the RDP server side then it is expected that the client connection will fail due to the workstation not being in the list. NLA is using Kerberos or NTLM authentication which cares about where you log on from as per above attribute. In addition if you take RDP out of the loop and browse to a share, for example, on the same RDP server from any OS workstation which is not in the <log onto> list it will also fail with the same error STATUS_INVALID_WORKSTATION!. 

    Available options here:
    1. Use this setting: HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-tcp "SecurityLayer", Default is 1 (SSL).  -> Set this to 0.
    2. On the client workstation, open the RDP file with Notepad and add the string enablecredsspsupport:i:0
    3. Add the source server that the user is connecting to into the LogonTo field.

    • Proposed as answer by AnguelS Tuesday, February 24, 2015 11:03 AM
    Thursday, February 12, 2015 11:18 PM
  • Many thanks, Ronald!

    IMHO the best workaround is #2. Here only a single enablecredsspsupport:i:0 line has to be added to the client's Default.rdp.

    #1 would require to do it on each RDP server machine.

    #3 would require to do it for every account and additionally you would allow that account to log in to the source computer which is what I absolutely don't want.

    Anguel


    • Edited by AnguelS Tuesday, February 24, 2015 11:22 AM
    Tuesday, February 24, 2015 11:02 AM
  • Unfortunately, the "Log on to..." account restriction does not only apply to RDP but also to normal network shares on the server, again I get the error message saying that the user is not allowed to log on from this (source) workstation if the source workstation is not explicitly entered. Very annoying.

    • Edited by AnguelS Monday, March 2, 2015 2:16 PM
    Monday, March 2, 2015 2:11 PM
  • Anguel, you finally understood how it works.
    Monday, March 2, 2015 2:16 PM
  • Hello all.

    I upgraded a few of my domain computers with Windows 10 and one of things I wanted to test was this issue on Windows 10 and guess what: it seems to be fixed!

    Can someone else try it as well and report back? I will make a few more tests myself in the days to come.

    Benoit


    Benjilafouine

    Friday, August 21, 2015 1:55 PM
  • Benoit, this is not fixed on my win10 x64 enterprise.
    Monday, August 31, 2015 10:53 AM
  • False hope... I just realized that I had set the account I was testing with to bypass the problem and as soon as I put back the restrictions, it ceased to work...

    Benoit


    Benjilafouine

    Tuesday, September 1, 2015 1:16 PM
  • Hi everyone.  I don't work for Microsoft but I do work extensively with their internal logon APIs and behaviors.  I believe I understand why this behavior is in fact really "by design" and not just saying that to cover up a bug.  This is an unfortunate case of how workstation control was implemented and how logons have evolved over the years. 

    Starting with the Account->Log on to... dialog where we specify "Logon Workstations":  This was originally just used to restrict what workstation consoles the user might approach and logon to with their domain account.  (Hence the "Log on to" verbiage).  If your workstation wasn't in the list, your authentication was denied. The way that is implemented is, the domain controller checks the value of the "Workstation" field in the NTLM auth or the Kerberos ticket request against the list, and blocks the authentication.  Simple enough.

    OK, now let's evolve the scenario.  We add RDP NLA, which is a separate initial authentication.  If the workstation is on the LAN, the NLA auth uses Kerberos directly to the DC.  If not, it uses NTLM to the RDP server.  In either case, the "Workstation" field of the authentication request is set to the value of the RDP client machine's name.  So what happens at the DC side?  The DC examines the Workstation value and compares it against the list, like before.  If it's not in the list, you are blocked.  Simple!  But in this case it seems like incorrect behavior to the mere humans who don't understand the underpinnings of its implementation.

    As far as I can think of, there isn't any way to truly fix this apart from overhauling the entire way authentication works in Windows.  The best you can do is to avoid using the "Log on to" feature to restrict your users.  Now let's talk about why that's not such a bad idea.

    Remember the "Workstation" field I mentioned, which is how the DC decides what to do with the request?  Well it turns out there is no mutual authentication between the computer account of the client and the DC.  The client simply volunteers whatever string value it wants in the "Workstation" field, and the DC trusts that.  This means that the entire feature you are relying on for security is really more of an "honor system" that only works if every RDP client in the universe chooses to tell the truth about its workstation name. 

    Not worried yet?  OK, here's a way to do it using trusted MS systems: Just name your standalone windows machine the same workstation name as one of the "allowed" logon workstations, and now the DC will believe it should be allowed.

    Gosh, what should we do?  Some other posters in this thread already have the solution.  In Windows-land, the best way to secure who is allowed to log on where is via group policy.  When you push a policy to a target server, that server does its own additional policing of who is trying to log in.  After the DC authenticates a user, the target server examines the user's token and checks the appropriate "Allow" and "Deny" logon policy items to see whether it should proceed or block.  This is immune to the "Workstation" field problem I describe, because no one in this case cares where the request is coming from, but rather whether the user is allowed to logon at the target server.  And this is exactly what you are trying to enforce, so it's a perfect fit.

    IMO: abandon the ancient "Log on workstations" feature because it just doesn't do anything useful.  In the NT days it might have been good enough because all the protocols were closed and it was pretty inconceivable that someone might connect "remotely" or with a machine that was not authorized and joined to the domain.  These days, it's worse than useless; just pretend security.  But fortunately we can use GPOs to do the real thing!

    • Proposed as answer by f3rrix Tuesday, September 15, 2015 4:14 PM
    Tuesday, September 15, 2015 4:13 PM
  • Hello,

    I understand what you are saying here but in a Remote Desktop scenario, I was used to allow "log on to" to generic users only. As an example, I have a environment where I did an automatic logon to some thin clients. This is easy because when a user reboots a computer, he is ending up on a desktop where all he sees is an icon to his remote desktop server. And of course, this generic logon has no right whatsoever to anything on the servers (shares, permissions, etc.).

    The reason for using the "log on to" option is to prevent a user from logging off from a thin client and try to logon with his own user name, then creating a huge security breach. So the "dumb" log-on account has no logon rights to any server. And remote desktop accounts have no right to logon to a local desktop (they only have logon rights to the servers).

    But now you are telling us that should someone crack the thin client and rename it to the name of one of the remote desktop servers, he would be able to logon locally to the workstation and then gain access to the data on the servers? That would definitely be a problem indeed as there are plenty of hacking tools for local workstations.

    But this new security is causing lots of issues. And what about computers not joined to a domain with the same name as one the the RDP servers? This is worth testing. Maybe then there should be another safer mechanism 

    Benoit.


    Benjilafouine

    Wednesday, September 16, 2015 1:40 AM
  • The reason for using the "log on to" option is to prevent a user from logging off from a thin client and try to logon with his own user name, then creating a huge security breach.

    You should push a group policy to the thin client instead. Allow logon only from your generic user.  This will give better security than what you are doing now.

    But now you are telling us that should someone crack the thin client and rename it to the name of one of the remote desktop servers, he would be able to logon locally to the workstation and then gain access to the data on the servers? That would definitely be a problem indeed as there are plenty of hacking tools for local workstations.

    I'm not completely sure I understand your threat modeling here.  But it sounds like the user already has access to server data because they are allowed to RDP to it.  Anyway, you should not use the workstation account restriction because it doesn't actually give you security, you just believe it does.  Group policy applied to the systems you want to protect will do much better and far more flexibly.

    But this new security is causing lots of issues. And what about computers not joined to a domain with the same name as one the the RDP servers? This is worth testing. Maybe then there should be another safer mechanism

    Again not sure what you mean entirely about security causing issues or another mechanism.  Group policy is a strong solution here.  Just throw away your workstation account limitations and use GPO to allow and block users where you want them.  Relying on the workstation name was never truly secure, and ever since untrusted clients and remoting were possible, it wasn't even a good attempt for pretending security.

    Wednesday, September 16, 2015 2:01 PM
  • The only easy work around I found to work was not logging them on using RDP. Instead use a Remote Desktop tool (for example Dameware Mini Remote Control or VNC) and log the user on there
    Tuesday, October 13, 2015 6:53 AM
  • Hi Everyone;

    I have banged through this problem several times in the past. The problem is bad wording of LOG ON TO in ADUC:

    http://www.urtech.ca/2016/01/solved-rdp-the-system-administrator-has-limited-the-computers-you-can-log-on-with-log-on-to/

    I hope this helps others.


    Ian Matthews www.urtech.ca www.commodore.ca

    Friday, January 15, 2016 11:28 PM
  • This is the easiest fix in my opinion (see full solution earlier in this thread):

    2. On the client workstation, open the RDP file with Notepad and add the string enablecredsspsupport:i:0

    Adding the computer in the "logon to" is easy but in some cases, you may have users signing in from several computers. Fixing the RDP file is easy.

    Benoit


    Benjilafouine

    Friday, January 15, 2016 11:57 PM
  • This answer gave me an idea on how to fix our issue.  We are using 2012 r2 domain.  And the way we fixed it is to add the client where the user is launching RDP to the list of logon to systems.

    In the case above, you have to add CLIENT_A to the list  together with CLIENT_X.  Where CLIENT_A is where the user is launching the RDP request to CLIENT_X.

    Saturday, January 23, 2016 12:04 AM
  • Thanks alot

    it works for me....

    Wednesday, October 12, 2016 5:30 PM
  • Thanks, it's working for me.
    Tuesday, July 3, 2018 1:39 PM