logo
Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Options
Go to last post Go to first unread
bgeraghty243  
#1 Posted : Saturday, April 2, 2016 1:50:20 AM(UTC)
bgeraghty243


Rank: Newbie

Joined: 4/1/2016(UTC)
Posts: 1
United States
Location: Wisconsin

Was thanked: 4 time(s) in 1 post(s)
Greetings,

Working as a sysadmin, I use ScreenConnect every day for a multitude of tasks, and quite successfully I might add. It's a great piece of software. I recently came up with an idea for a companion-tool to ScreenConnect that ended up being quite handy for supporting end-users in my experience, so I thought I'd upload and share it.

https://github.com/bgera...cessAsUser-ScreenConnect

Code:

Background/Goal: 
On the Host page of the web interface, input sent to the "Commands" Tab of any Windows Guest, is executed on the machine via the ScreenConnect service, which results in the command being executed as the SID "NT Authority\SYSTEM".  This is not a problem, however I wanted to also be able to send commands to the Guest and have them be executed within the interactive user session (Console Session) of the machine, as the user who is currently logged in to that session, whoever that might be at that point.  I found that from time to time, I needed to execute certain commands as the user to get the desired result, but was not able to without connecting into the session and taking physical control of the user's session / using the toolbox.


Description:
The console program I wrote to accomplish this is called "rpau.exe" (Run Process As User). It was written in PureBasic 5.41, and accomplishes this goal with very small footprint on the system (19kb).  I placed a copy of it in the C:\Windows directory (PATH) to be able to run it from the Command Tab by simply calling it by name:

C:\Windows\system32>rpau

Error: No Options / Parameters Given.

       [Run Process As User] v0.32.131

Syntax1: rpau.exe --hidden "<ProgramName>" "<CmdLineArgs>" "<WorkingDirectory>"
       : You can optionally include "--hidden" to visibly hide the executed
       : program. Enclose parameters in double-quotes as shown.
       : The only required parameter is <ProgramName>. However, if you want
       : to specify <WorkingDirectory> without specifying <CmdLineArgs>,
       : <CmdLineArgs> must still be passed as: "". (Empty String).

Example: rpau.exe "cmd.exe" "/c ipconfig > test.txt" "C:\ProgramData"


Syntax2: rpau.exe --username
       : Returns the Username of the account in the Console Session. No 
       : Additional Parameters Expected.

Example: rpau.exe --username

There are currently 2 "modes" it works in. The program can only be run from the SYSTEM account, and will do nothing except exit if launched as a normal user. (Security/Redundant Use Case)
- Syntax 1 is for running a process as the user in their session, with the option of suppressing the visibility of any windows with --hidden. ('--hidden' option is for running things like batch scripts, etc. without visually interrupting the user, or running the risk of stealing their window focus.)  It is basically a command-line interface to the CreateProcess() API (ProgramName, Arguements, WorkingDirectory can be specified), while impersonating the logged on user in an environment block.
- Syntax 2 returns printed information to the Command Tab, specifically the username of the account which is logged in to the console session. ScreenConnect already provides this information, but it's just there for convenience.

(See Screenshots Folder for Examples)


Limitations/ToDo:
- Currently, does not support Terminal-Services style configurations (More than one concurrent console session).  I plan to add an option to enumerate the WTS Sessions, and to select which one specifically to direct the commands to, but haven't had time to yet.
- Plan to add other options to perform other actions as the user.

It is a pretty short program at this point, so it shouldn't be too difficult to translate to other languages. If you do not have access to a PureBasic compiler, a binary is available at the Git.

thanks 4 users thanked bgeraghty243 for this useful post.
rich2323 on 8/8/2016(UTC), MannyTC on 8/8/2016(UTC), cristobalcat on 8/10/2016(UTC), KBrownConsulting on 9/30/2016(UTC)
rich2323  
#2 Posted : Monday, August 8, 2016 10:57:03 PM(UTC)
rich2323


Rank: Advanced Member

Medals: ScreenConnect Advisor: Focus Group MemberLevel 1: Random Act of Kindness! Received One Thanks!

Joined: 1/28/2014(UTC)
Posts: 93
Location: daphne, al

Thanks: 47 times
Was thanked: 3 time(s) in 3 post(s)
Very nice!!!

Rich
yochaigal  
#3 Posted : Tuesday, August 9, 2016 9:03:53 PM(UTC)
yochaigal


Rank: Advanced Member

Medals: ScreenConnect Advisor: Focus Group MemberLevel 1: Random Act of Kindness! Received One Thanks!

Joined: 7/24/2013(UTC)
Posts: 44
Location: boston

Thanks: 1 times
Was thanked: 7 time(s) in 6 post(s)
Thanks for this.

I've placed the binary in C:\Windows; however when I execute any command I get:

Error: Failed to query User Token.

Example:

C:\Windows\system32>rpau.exe "cmd.exe" "/c ipconfig > test.txt" "C:\ProgramData"

Attempting To Run: "cmd.exe /c ipconfig > test.txt" in Directory: "C:\ProgramData"

Error: Failed to query User Token.
The Program Failed To Execute. Please Check Syntax of Commandline Text.

What am I doing wrong?
Thanks
bgeraghty-243  
#4 Posted : Wednesday, August 10, 2016 9:10:27 PM(UTC)
bgeraghty-243


Rank: Guest

Joined: 7/28/2016(UTC)
Posts: 3
United States
Location: Milwaukee

Sorry for the delay, seems I keep getting locked out of my account here...

Anyways, the error you describe indicates that the program is not successfully calling the Windows API "WTSQueryUserToken(dwSessionID, lpTokenHandle)"

The only way I can reproduce this error is if there is no user signed into an 'interactive' or 'physical' session on the machine. If there is no user logged in, there is no session 1 to pass to this function. Is there a user signed in when you try to run the command?
yochaigal  
#5 Posted : Wednesday, August 10, 2016 9:13:12 PM(UTC)
yochaigal


Rank: Advanced Member

Medals: ScreenConnect Advisor: Focus Group MemberLevel 1: Random Act of Kindness! Received One Thanks!

Joined: 7/24/2013(UTC)
Posts: 44
Location: boston

Thanks: 1 times
Was thanked: 7 time(s) in 6 post(s)
Yes, a user is signed in when I'm running this command from screenconnect.
bgeraghty-243  
#6 Posted : Wednesday, August 10, 2016 9:19:03 PM(UTC)
bgeraghty-243


Rank: Guest

Joined: 7/28/2016(UTC)
Posts: 3
United States
Location: Milwaukee

For more details:

The error is happening because line 36 is failing in the below source. The only [in] parameter (I believe) is "dwSessionId", so it depends on having a user logged in. Also, if this is a terminal-services (rds) machine, it may not work as expected, because I do not enumerate all/multiple sessions, only the first interactive user session. I may add support for this in the future if it becomes a need.

https://github.com/bgera...ob/master/Source/rpau.pb
yochaigal  
#7 Posted : Thursday, August 11, 2016 1:08:55 PM(UTC)
yochaigal


Rank: Advanced Member

Medals: ScreenConnect Advisor: Focus Group MemberLevel 1: Random Act of Kindness! Received One Thanks!

Joined: 7/24/2013(UTC)
Posts: 44
Location: boston

Thanks: 1 times
Was thanked: 7 time(s) in 6 post(s)
A reboot seems to have resolved this issue!

I'm trying to get this command to work:

rpau.exe --hidden "cmd.exe" "/c wuauclt.exe /detectnow /updatenow"

Does that syntax seem correct?

However it does nothing. When I use the /k switch, a command window opens and says, "C:\Windows\system32\wuauclt.exe' is not recognized as an internal or external command,operable program or batch file."

I think perhaps it's because it's running as the system user?

Either way, thanks for this app, it might solve some pretty big problems I've been having with not being able to run commands! For more info, see my post here:
http://forum.screenconne...xe-issues.aspx#post34625

Edited by user Thursday, August 11, 2016 1:18:57 PM(UTC)  | Reason: Not specified

bgeraghty-243  
#8 Posted : Friday, August 12, 2016 1:44:52 PM(UTC)
bgeraghty-243


Rank: Guest

Joined: 7/28/2016(UTC)
Posts: 3
United States
Location: Milwaukee

I can verify that C:\Windows\System32\wuauclt.exe is a valid file on my 64-bit system, but it looks like windows is not finding it for some reason. Maybe either pass the full path to that exe? or maybe set the <workingdirectory> parameter to "C:\Windows\System32"
yochaigal  
#9 Posted : Friday, August 12, 2016 1:57:26 PM(UTC)
yochaigal


Rank: Advanced Member

Medals: ScreenConnect Advisor: Focus Group MemberLevel 1: Random Act of Kindness! Received One Thanks!

Joined: 7/24/2013(UTC)
Posts: 44
Location: boston

Thanks: 1 times
Was thanked: 7 time(s) in 6 post(s)
Here's the thing: if you try other files in that directory, they work! However if you do the dir command on c:\windows\system32, you'll see that only about half the files appear.
Weird, right?
powellap  
#10 Posted : Friday, August 12, 2016 3:16:44 PM(UTC)
powellap


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 2/16/2014(UTC)
Posts: 95
United States

Thanks: 3 times
Was thanked: 8 time(s) in 7 post(s)
I think this problem may in fact be a bug in ScreenConnect 5.6. In the following thread the poster found that SC 5.6 is returning x86 even on x64 machines when testing the processor type, I have confirmed this behavior. Even if the SC exe is 32bit it should still be able to determine the processor type as x64.

http://forum.screenconne...-machines.aspx#post34524

If the SC client is in fact 32bit, running on a 64bit version of Windows, Windows x64 will by default, redirect you from the system32 directory to the syswow64 directory. If you look, wuauclt.exe is not in that directory, and is the reason you are getting file not found.

Edited by user Friday, August 12, 2016 3:25:25 PM(UTC)  | Reason: Not specified

yochaigal  
#11 Posted : Friday, August 12, 2016 3:27:50 PM(UTC)
yochaigal


Rank: Advanced Member

Medals: ScreenConnect Advisor: Focus Group MemberLevel 1: Random Act of Kindness! Received One Thanks!

Joined: 7/24/2013(UTC)
Posts: 44
Location: boston

Thanks: 1 times
Was thanked: 7 time(s) in 6 post(s)
If I run:

echo %PROCESSOR_ARCHITECTURE%"

From any machine, regardless of architecture, it returns:

x86

yochaigal  
#12 Posted : Friday, August 12, 2016 3:29:51 PM(UTC)
yochaigal


Rank: Advanced Member

Medals: ScreenConnect Advisor: Focus Group MemberLevel 1: Random Act of Kindness! Received One Thanks!

Joined: 7/24/2013(UTC)
Posts: 44
Location: boston

Thanks: 1 times
Was thanked: 7 time(s) in 6 post(s)
Originally Posted by: powellap Go to Quoted Post


If the SC client is in fact 32bit, running on a 64bit version of Windows, Windows x64 will by default, redirect you from the system32 directory to the syswow64 directory. If you look, wuauclt.exe is not in that directory, and is the reason you are getting file not found.


Why is it that when I put the full path (c:\windows\system32) I get the same error?
powellap  
#13 Posted : Friday, August 12, 2016 3:50:04 PM(UTC)
powellap


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 2/16/2014(UTC)
Posts: 95
United States

Thanks: 3 times
Was thanked: 8 time(s) in 7 post(s)
Windows does this internally/intentionally for 32bit processes on 64bit OSs. See this MS KB...
https://msdn.microsoft.c...mp;MSPPError=-2147217396

yochaigal  
#14 Posted : Friday, August 12, 2016 6:44:44 PM(UTC)
yochaigal


Rank: Advanced Member

Medals: ScreenConnect Advisor: Focus Group MemberLevel 1: Random Act of Kindness! Received One Thanks!

Joined: 7/24/2013(UTC)
Posts: 44
Location: boston

Thanks: 1 times
Was thanked: 7 time(s) in 6 post(s)
Thank you.

Forgive my ignorance here - but how would I compensate for this scenario without altering the system path? If Windows is redirecting my c:\windows\system32 commands to %windir%\SysWOW64, that is.
Is there a way (using rpau) to run as Administrator (with the proper paths)?
powellap  
#15 Posted : Friday, August 12, 2016 6:58:50 PM(UTC)
powellap


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 2/16/2014(UTC)
Posts: 95
United States

Thanks: 3 times
Was thanked: 8 time(s) in 7 post(s)
At this point its likely SC will have to fix this. I'm not a programmer, but my experience here comes from working with a scripting language called kixtart. Kix only has a 32bit app, and we get around this folder redirection/limitation by disabling a setting the developer opened up to us. I have no idea how this is implemented in code, but its exposed to us by Disabling Wow64FileRedirection.

yochaigal  
#16 Posted : Friday, August 12, 2016 7:00:19 PM(UTC)
yochaigal


Rank: Advanced Member

Medals: ScreenConnect Advisor: Focus Group MemberLevel 1: Random Act of Kindness! Received One Thanks!

Joined: 7/24/2013(UTC)
Posts: 44
Location: boston

Thanks: 1 times
Was thanked: 7 time(s) in 6 post(s)
Understood. Hopefully SC 6.0 will resolve this (assuming they're aware of it).
Thanks for your help!
gb5102  
#17 Posted : Saturday, September 17, 2016 6:10:39 AM(UTC)
gb5102


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 3/14/2013(UTC)
Posts: 42
Location: USA

Thanks: 13 times
Was thanked: 2 time(s) in 2 post(s)
For anyone affected by the 32-bit client/SysWOW64 issue, there is a feature request to get this fixed:
http://product.screencon...bit-client-on-64-bit-os/
Users browsing this topic
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.