I have a rather large PS Script that opens a windows form. There is an odd behavior that I cant seem to figure out. My system is Windows 10 1809. I am setting the Focus method on the form when it loads to put it in the foreground for the user. The odd behavior is when I lock my screen with Window Key+L. The form is still visible and USABLE. All the controls work on the form work as if the screen was not locked. I should also point out that the script requires run as admin so the form is running as admin as well.
Any ideas on what is going on and how I can prevent this? I would really like to keep the Focus method in the script and not have the form usable when the screen is locked. What add even more of a mystery to this problem is that it is not 100% repeatable. On some occasions, when I lock the screen, the form is not visible.
Any ideas/suggestions are very much appreciated. Thanks in advance.
My first gut instinct is that should not be possible. It would be a huge security issue since you could overlay the lock screen and have someone enter credentials in our app to steal them. This is old, but same sentiment:
My recommendation is to post your question on a forum dedicated to .NET forms. All that powershell is doing is initiating the .NET form. Also, you are going to need to have your code posted somewhere. Asking questions about why code is doing something is like telling someone your car is making a weird noise but they can’t look at it. Minimally, the community is going to want to see the form properties that are set.
Thanks Rob. I too felt it was a security hole. The script is huge, way to big to post in entirety, and yes I agree, general questions like mine are not a good idea. What I will do is pull the relevant parts to a much smaller script and see if it still behaves this way, then go from there.
What I have done is change the script to only bring up the form, and the behavior still exists, so it should not be that difficult to put together a smaller script for testing. The overall script performs a security audit on the system, generates the audit report in HTML, then brings up the windows form so the user can archive the event logs, hence the reason it needs admin since the security log is involved.
Other thoughts I have is that this behavior exists only in conjunction with something else that may be running on the system as it is not 100% reproducible. And, I cannot reproduce at all on my home system running Win10/Pro/1903. This occurs on my corporate laptop which is hardened pretty tight along with TONS of monitoring
Very odd and maybe too difficult to troubleshoot. I will likely just move on with my life and have a nice day. Thanks again Rob.
OK Rob, I think I have it figured out. My theory on another program causing the issue seems to be correct. It appears to be caused by BeyondTrust Run Elevated.
The script contains #Requires -RunAsAdministrator. The way I run it elevated is using the tool above to launch an elevated shell, then I run the script from there.
If I remove the Requires, and run in a non elevated shell, no joy, the form does NOT survive the screen lock. If I leave the Requires removed and run from the Run Elevated shell, the form survives the screen lock, with our without the Requires. So, my issue appears to be caused by RunElevated.