0
Background: We have software that (remotely) retrieves information from a Windows desktop. The desktop needs to be locked, but if we do that the simple way, Windows thinks no-one is looking at the screen and stops updating it. To prevent that, we open an RDP session to the computer. This locks the screen as a side-effect, but the original desktop still gets updated.
We have a small program (called 'lockscreen') based on the Remote Desktop Active X Control to open an RDP session. It appears to behave itself just like the Microsoft Terminal Services Client (mstsc.exe) for all intents and purposes of this question. Any behavior described below holds for both lockscreen and mstsc. All results are from a Windows 7 computer.
Running the program on the target machine, when trying to connect to the target machine (localhost), the error "Your computer could not connect to another console session on the remote computer because you already have a console session in progress" appears (errorocode 1800). This happens regardless of whether I use 'localhost', 127.0.0.1, the name, or the IP address of the target computer. It appears to be a check in the Remote Desktop Active X Control that can be bypassed by using the IP address 127.0.0.2 to access the local machine. Using 127.0.0.2 indeeds allows the connection to proceed and a logon attempt to be made. However, then the remote desktop only shows "Access Denied" and an OK button. Pressing the button or waiting a minute causes the session to be disconnected.
I have been unable to find out why this Access Denied error is given. There are no entries in the event log that shed some light on this. It only happens when trying to connect from the target computer itself: connecting from another computer succeeds.
Some experiments I did: When trying to connect from another computer but going through a proxy that runs on the target computer, it succeeds - it does not matter whether the proxy connects to localhost or to 127.0.0.2. When connecting from the target computer, going through the same proxy, it fails, again regardless of whether the proxy connects to localhost or 127.0.0.2. It seems that only the location of the program setring up the connection is relevant.
In all the scenarios described above, FreeRDP manages to connect successfully. Apparently there are no authentication or authorization issues, or any other fundamental issues that would prohibit a connection to be made.
My two questions: Why am I getting access denied when setting up an RDP session from one computer to itself? Is there anything I can do about it?
Does the target computer have to a physical one? Because I would move this (legacy) desktop software into a virtual machine. Then it is protected and you can configure it to never lock, no screensaver, ... without any security implications. – Robert – 2019-11-08T16:14:48.660
Target computer can be either VM or physical. What software it runs is up to the customer to decide, and the same holds for the security requirements. We cannot put restrictions on that. – Jeroen ter Hofstede – 2019-11-11T07:42:58.427
So we are not talking about one PC running this set-up but a whole fleet of installations!? If I were you I would really try to get rid of this bad software that requires an unlocked desktop. – Robert – 2019-11-11T08:43:22.203