Delphi 10.4 : Unlock Windows by call to Windows API

[gioma 19]

Hello,
I am creating a remote control program using the WebRTC.
I have a problem, however, when the user I am connected to locks the screen I cannot access the welcome screen. In fact, at that moment, it seems that the streaming of the desktop is interrupted, while the connection between the two clients remains active, so they can exchange messages.
Assuming the logged in user knows the access credentials, I'm looking for a way to re-login via the windows API and unlock the screen.
It's possible to do it?
I tried with LogonUser, but although the result is positive it does not unlock access.
Maybe I should try using PostMessage?

[Der schöne Günther 316]

The login screen is an entirely different "desktop" (not to be confused with "Virtual desktops" which were introduced with Windows 10), much like an elevation prompt ("user account control").

 

An application that runs without administrative privileges cannot access that "secure desktop" the login screen is running on. You can, for example, also see this with other solutions like TeamViewer or AnyDesk: When they don't have administrative privileges and the user locks his account, they can't do anything.

Edited March 26, 2021 by Der schöne Günther

[gioma 19]

3 minutes ago, Der schöne Günther said:

The login screen is an entirely different "desktop" (not to be confused with "Virtual desktops" which were introduced with Windows 10), much like an elevation prompt ("user account control").

 

An application that runs without administrative privileges cannot access that "secure desktop" the login screen is running on. You can, for example, also see this with other solutions like TeamViewer or AnyDesk: When they don't have administrative privileges and the user locks his account, they can't do anything.

My application not only has administrator privileges, but runs as a System user.

[Der schöne Günther 316]

I believe you will still have to get familiar with Windows Desktops:

Desktops - Win32 apps | Microsoft Docs

Edited March 26, 2021 by Der schöne Günther

[gioma 19]

13 minutes ago, Der schöne Günther said:

I believe you will still have to get familiar with Windows Desktops:

Desktops - Win32 apps | Microsoft Docs

Thanks for the hint, I deepen the subject.👍
Of course it wouldn't be bad if someone had already solved it!
After all, the community is also useful for this.. 😋

[Wil van Antwerpen 25]

There's no supported way to do what you want and that's a good thing.

[gioma 19]

10 minutes ago, Wil van Antwerpen said:

There's no supported way to do what you want and that's a good thing.

What do you mean?

 

I don't want to bypass the windows login, but I would like to do it through a program controlled by a user who knows their login credentials.

[Wil van Antwerpen 25]

I mean that the secure desktop cannot be programmatically controlled from another session and desktop.
This is a security measure in Windows and not even a system user can get around that.

[gioma 19]

18 minutes ago, Wil van Antwerpen said:

I mean that the secure desktop cannot be programmatically controlled from another session and desktop.
This is a security measure in Windows and not even a system user can get around that.

There are remote control programs that let you choose which session to open the connection in, how do they do it?

[Wil van Antwerpen 25]

I still think you're just going to waste a lot of energy on fighting the system here, but OK, your choice.

You can enumerate the sessions for example: https://docs.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-lsaenumeratelogonsessions

You can determine the secure desktop using: https://stackoverflow.com/questions/4260878/openinputdesktop-to-determine-secure-login-desktop

Then there's WTSQueryUserToken to get a user's token and https://docs.microsoft.com/en-us/windows/win32/api/securitybaseapi/nf-securitybaseapi-impersonateloggedonuser?redirectedfrom=MSDN

to use that.

Good luck!

[Guest]

3 hours ago, Wil van Antwerpen said:

I mean that the secure desktop cannot be programmatically controlled from another session and desktop.
This is a security measure in Windows and not even a system user can get around that.

I think there is another side of this, as there is a method and it is documented by Microsoft,

please refer to https://docs.microsoft.com/en-us/windows/win32/secauthn/winlogon-and-credential-providers

To read more about credential providers, also the dll or the plugin to be implemented known as GINA

https://docs.microsoft.com/en-us/windows/win32/secauthn/winlogon-and-gina

in the above link give extra attention to this

Quote

Interaction with Network Providers    You can configure a system to support zero or more network providers.

As this is way harder than how it looks, as accessing network and sockets in a very controlled and isolated dll will be hard to get it right and near impossible due the short documentation around it.

 

But as Wil, it is a good thing, as i only saw this in trojan and malicious software, also it would be very hard to implement in Delphi/Pascal , as most of its functionality are complex callbacks, and at any case or stage and on any sort of raise or unexpected response form your GINA the system will not joke about it and will perform a full reboot, also you can't debug that thing.

[Wil van Antwerpen 25]

A credential provider might work, but you would implement that in C/C++ and then debug it via a remote debugger.
Doing that in delphi would be very very painful.

I think that a GINA DLL no longer works since Vista?

I haven't checked, but you probably also need to get a special agreement with Microsoft or I would expect at least a kernel mode signing certificate requirement for this type of thing.

Fun, but not for the faint of heart.

[gioma 19]

On 3/26/2021 at 8:03 PM, Wil van Antwerpen said:

 

Fun, but not for the faint of heart.

 

ok, I understand the situation!

Thank you for the valuable insights, now I'll have some fun! : D

[serdor444 0]

Did you succeed in the end? What method did you use for this? 

[eivindbakkestuen 47]

OP, you may find something here:

 

https://github.com/CloudDelphi/RTC-Portal-VCL

 

I have not looked at the source of the above, but when the product was known as Nexus Portal, logging in via remote control worked. If it hasn't been dumbed down for the git release, it's probably in there somewhere.