Derek Posted July 1, 2019 Share Posted July 1, 2019 I have a few accounts in AD that are restricted to only allow Logon from certain hosts. I tried turning off the Logon Restriction, and it works. I tried adding the PWS server in, but the Browser Based RDP Console does not work. How can I determine what the "name" of the Computer that I need to allow in AD? Does the Browser Based Launcher generate one randomly? Link to comment Share on other sites More sharing options...
support Posted July 2, 2019 Share Posted July 2, 2019 Hello, Could you provide us a screenshot of the restriction you're referring to, and we'll do some testing to see if we can reproduce the issue? From our understanding of the feature we think you're talking about, you specify which hosts you are allowed "to" logon, not "from" which hosts - but maybe we are thinking of the wrong setting in AD. Regards Click Studios Link to comment Share on other sites More sharing options...
Derek Posted July 2, 2019 Author Share Posted July 2, 2019 The feature has a different function on Windows 8.1 and above. It not only restricts where you can logon TO, but it also restricts where you can connect FROM because it does the Auth on your local PC and then does a Token to the target machine. This is the Default behavior. See this long thread. https://social.technet.microsoft.com/Forums/office/en-US/fab6f026-86c2-47e0-b485-2ac40623051f/remote-desktop-denies-login?forum=w8itprosecurity About 80% of the way down it has a long explanation of this change in how Windows 8.1 and Server 2012 and higher handle it. Here's a good comment that Microsoft support responded with to a user who opened a case: 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. I'm trying to solve my issue with option 3. I just need to know the Source Server's name that is being used to connect to the Destination Host when using the Browser Based Client. Link to comment Share on other sites More sharing options...
Derek Posted July 10, 2019 Author Share Posted July 10, 2019 Any update on this from Click Studios? I just want to determine the Computer name that is used to connect when using the Browser Based Remote Desktop session. Link to comment Share on other sites More sharing options...
support Posted July 10, 2019 Share Posted July 10, 2019 Hi Derek, Sorry, we've missed your updated post. It will task us some time to do this testing, but the computer name should be your Passwordstate web server name - as this is where gateway is installed by default. And if you have a look at the gateway.conf file in the Gateway folder, we also have credSSP set to true by default. Regards Click Studios Link to comment Share on other sites More sharing options...
Derek Posted July 11, 2019 Author Share Posted July 11, 2019 I set the credSSP setting to False and it didn't change my test results. I still got the message that the Remote Account couldn't connect. We will probably disable the "Logon To" feature for our service accounts going forward. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.