none
cant remote desktop to a computers defined in "log on to..."

    Question

  • Hello all.

    I have a strange issue. I have to limit vpn users so they can log to only some computers. So, they vpn, router let them through (vpn authentication), they try to remote desktop to computer  but get message they are not allowed even i  u put that computer in "log on to... "section in AD user properties. When i try to log as on of them from inside (no vpn) i get the same message. But, when i give them "All computers" in "log on to.." they can log on. What am i doing wrong?



    • Edited by John Deeman Tuesday, February 14, 2017 2:02 PM
    Monday, February 13, 2017 5:44 PM

Answers

  • OK, i found the solution. Next to last post on following link:

    https://social.technet.microsoft.com/Forums/windows/en-US/954975f2-743c-413f-8cc3-037bf3e35b09/remote-desktop-the-local-security-authority-cannot-be-contacted?forum=w7itpronetworking

    "I know this is a really old thread. But I *finally* figured this out with what for me is the DEFINITIVE solution. I get the "local security authority could not be contacted" error too, when attempting to connect via RDP over the internet from a computer that is NOT a member of the domain. Removing NLA is just not an option, as I am just flat out not willing to sacrifice security for convenience. So here's the solution, assuming the user is NOT authorized to log onto every computer on the domain.

    That is to say, you have identified in the user's account properties the specific computers they are allowed to log on to. If you change this to "all computers" the problem goes away. But it also sacrifices your internal security by allowing the user to log on to any domain computer - probably not desired. So what to do?

     If remoting in from a computer that is not a domain member (such as your personal computer at home) then on the AD DS domain server open the AD Computers and Users applet. Then in the users container select/open the specific user account being used.

    In the user account dialog under the Account tab, click the "Log On To" button.  Now add the name of the non-domain computer they are remoting in from, and that solves this problem without sacrificing NLA or any other security.

    If you're using health policies on the NPS, that just adds another layer of security, and I highly recommend it if you're going to allow users to log into domain computers remotely, from non-domain computers."




    Tuesday, February 14, 2017 9:43 AM

All replies

  • Hi,

    When i try to log as on of them from inside (no vpn) i get the same message. But, when i give them "All computers" in "log on to.." they can log on. What am i doing wrong?

    >>>If you configure Log On To with all computers, then the user can logon, I suggest you try to check if the computer name is correct. You should type the computer’s NetBIOS name or DNS name.

    In addition, if you want the users could logon remotely, you need give users with logon through remote desktop service permission and add user to the Remote Desktop Users group.

    For detailed information, please refer to the article below.

    “Allow Logon through Terminal Services” group policy and “Remote Desktop Users” group

    https://blogs.technet.microsoft.com/askperf/2011/09/09/allow-logon-through-terminal-services-group-policy-and-remote-desktop-users-group/

    Best Regards,

    Jay


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, February 14, 2017 2:22 AM
    Moderator
  • I (double) checked everything but still same message. It only works when i give them "All Computers".

    They can log locally, but only trough RDP when "All computers" is on. I don't get it...

    Tuesday, February 14, 2017 7:50 AM
  • OK, i found the solution. Next to last post on following link:

    https://social.technet.microsoft.com/Forums/windows/en-US/954975f2-743c-413f-8cc3-037bf3e35b09/remote-desktop-the-local-security-authority-cannot-be-contacted?forum=w7itpronetworking

    "I know this is a really old thread. But I *finally* figured this out with what for me is the DEFINITIVE solution. I get the "local security authority could not be contacted" error too, when attempting to connect via RDP over the internet from a computer that is NOT a member of the domain. Removing NLA is just not an option, as I am just flat out not willing to sacrifice security for convenience. So here's the solution, assuming the user is NOT authorized to log onto every computer on the domain.

    That is to say, you have identified in the user's account properties the specific computers they are allowed to log on to. If you change this to "all computers" the problem goes away. But it also sacrifices your internal security by allowing the user to log on to any domain computer - probably not desired. So what to do?

     If remoting in from a computer that is not a domain member (such as your personal computer at home) then on the AD DS domain server open the AD Computers and Users applet. Then in the users container select/open the specific user account being used.

    In the user account dialog under the Account tab, click the "Log On To" button.  Now add the name of the non-domain computer they are remoting in from, and that solves this problem without sacrificing NLA or any other security.

    If you're using health policies on the NPS, that just adds another layer of security, and I highly recommend it if you're going to allow users to log into domain computers remotely, from non-domain computers."




    Tuesday, February 14, 2017 9:43 AM
  • OK, i found the solution. Next to last post on following link:


    Thank you for sharing the solution. That would be nice if you could change the topic name to something more understandable for others.


    Mahdi Tehrani   |     |   www.mahditehrani.ir
    Please click on Propose As Answer or to mark this post as and helpful for other people.
    This posting is provided AS-IS with no warranties, and confers no rights.

    Tuesday, February 14, 2017 1:16 PM
    Moderator