2

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?

3
  • 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
    Nov 8, 2019 at 16:14
  • 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. Nov 11, 2019 at 7:42
  • 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
    Nov 11, 2019 at 8:43

3 Answers 3

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.

6
  • Thanks. I tried all these and they don't work. As I wrote, using 127.0.0.2 prevents the error "Your computer could not connect to another console session on the remote computer because you already have a console session in progress" from occurring (the check apparently baked in into the RDP client library), but then it gets me stuck on the "Access Denied" screen after connecting. Nov 11, 2019 at 7:40
  • So this bypasses one problem. Try: (1) mstsc /admin, (2) the workaround in this post.
    – harrymc
    Nov 11, 2019 at 7:48
  • Unfortunately, that doesn't work. Nov 11, 2019 at 10:14
  • Probably then the purpose of this limitation on localhost was to avoid a bug in RDP. The limitation can be worked around, as in my answer, but RDP just cannot work across the loopback adapter. It seems like there is no solution except using a third-party product such as FreeRDP, TeamViewer or other. Or of going through the internet (if the router supports it).
    – harrymc
    Nov 11, 2019 at 10:36
  • Yes, I fear that's the case. Nov 11, 2019 at 11:35
1

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.

0
0

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.

8
  • FreeRDP manages to connect to the same computer without the terminal services .dll file being patched. I guess that it's something in the communication between the server and the microsoft RDP client libraries that triggers this behavior, which gives me slight hopes that it can be circumvented if identified. Nov 8, 2019 at 14:55
  • The question becomes can you use FreeRDP and connect to localhost without a problem? If so, that is of course a suitable workaround
    – LPChip
    Nov 8, 2019 at 15:10
  • Indeed - unfortunately FreeRDP has other issues. This question actually comes from trying to find an alternative for it :) Nov 8, 2019 at 15:16
  • Have you tried it without RDP as suggested in my answer? Simply make sure a 2nd user is on the computer and switch to that user, so both users are logged in at the same time?
    – LPChip
    Nov 8, 2019 at 15:18
  • Yes, but that causes Windows to stop updating the screen for the first user, so it is useless for our purpose. RDP keeps the desktop 'alive'. I know of no other way to achieve that. Nov 8, 2019 at 15:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.