RDP to computer from same computer fails. Why?

Question

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?

Answer 1

Connecting to Terminal Server service running on localhost (or IP 127.0.0.1), ends in session disconnected or unable to connect. This behavior is explicitly baked into RDP by Microsoft, and the reason for it is lost in time.

Below are some workarounds that bypass that limitation. As you can see, the Microsoft developer that put this in RDP didn't exert himself. The workarounds may still work for the latest Windows 10, but I haven't tested it.

1. Connect Remote Desktop Connection to 127.0.0.2, which is an alias to 127.0.0.1.

2. Connect at non-standard port, other than the default (3389).

3. Run mstsc.exe simulated as another operating system.
   This involves copying from the C:\Windows\System32 both mstsc.exe and mstscax.dll to a new folder, right-click the copied mstsc.exe, selecting Properties, Compatibility tab, and tick "Run this program in compatibility mode" for "Windows 98 / Windows Me".

Note that when logging in in Remote Desktop session, do so as a different user, or you may be logging yourself out forcefully.

Answer 2

My question would be what service is it running under? If you are able to have it execute under system it should continue to run regardless of a lock screen or anyone logging in. I had to do this for sharepoint automation and some scripting, this way end user never sees it, no one has to be logged in etc and with the gpo would kick off anytime the system was rebooted.

Sorry to clarify, your application. Not rdp.The application/software you are utilizing on the systems for data collection. The problem you have is what account/service its being executed under. There are plenty of commercial applications that can scrape data off your computer regardless of anyone on the computer or not, without any need for an rdp connection to trick the system. Most of these applications execute under the computers system account.

Answer 3

This is indeed working as designed. Normally, you cannot initiate an RDP session to the same computer, due to a loopback.

It is possible to patch the terminal services .dll file to allow this, but it is not a nice solution, because with every windows update, it will break, and the patch have to be applied again, which is difficult because you have to search for a patch for the new version of the file.

I would look into the reason why the desktop needs to be locked. Maybe you can adjust that so the machine is not actually locked, or the lock is different.

For example, you can choose to switch to a different user. The first user is still running in the background in a "locked" state, but it may still be in a state that works for you. The other user is in a different state and you can test to lock that user or maybe even log out.