Solved

Limitations in worklets // scope worklets run in?

  • 11 November 2023
  • 1 reply
  • 65 views
N
Userlevel 1
Badge

There are certain limitations I’ve come across with PS scripts in worklets and I’m curious A) if they’re possible, or B) how exactly worklets invoke the scripts on remote endpoints.  I’ve tried finding information on how exactly worklets run scripts on remote endpoints but it’s pretty obfuscated. 

Examples:

If I try calling a static .NET method for a Windows form element, like a notification popup, nothing will display on the remote endpoint.  Example below:

[System.Windows.MessageBox]::Show(
    "Title", 
    "Message", 
    [System.Windows.MessageBoxButton]::OK, 
    [System.Windows.MessageBoxImage]::Information)

Or if I try invoking rest method to send a message to Teams using a public incoming webhook, it will not post.  Example below:

Invoke-RestMethod -Uri $webhookUri -Method POST -Body $json -ContentType "application/json"

How exactly do worklets run these scripts on remote endpoints, and are there ways to get examples such as these to work?

icon

Best answer by AnthonyM-Automox 13 November 2023, 16:07

View original

1 reply

AnthonyM-Automox
Userlevel 1

Good morning @Nvlddmkm !

 

Reading through your post, the questions I glean are:

  1. In what context does Automox execute Worklet scripts as on an endpoint?
  2. How can I allow Automox to interact with sessions, such as the currently active user?
  3. What’s going wrong with my Invoke-RestMethod calls?

 

I’ll start with #1 and, since you referenced .NET assemblies, I’ll be speaking primarily in regard to Windows as the behavior is slightly different on Linux and Mac:

  • On Windows devices, the Automox agent installs and executes under the NT SYSTEM principal
    • For those  that may read this and are less familiar with Windows, this is the Windows incarnation of the root user
  • This is why the commands you reference above produce unexpected results - your MessageBox calls are attempting to present to the SYSTEM user which has no console session.

 

Now on the second point, the language required to achieve message boxes and process starts impersonating other ( ex: logged-in ) users, is actually quite an endeavor. We have to dip into C# for Interop capability to recruit the WinAPI.

 

Fortunately, we’ve just within the last few weeks released our Worklet Development Kit ( WDK ), which provides the functionality you’re looking for:

** Note: There is no “import” or manual steps required to implement these WDK functions, that’s all handled behind-the-scenes and as such you can simply call any functions listed in the links above **

 

Lastly, aside from environmental cases such as network traffic filtering / control solutions ( switch PNAC, network proxies, etc. ) where the solution defaults to a DENY action if the user isn’t authenticated through something like 802.1x ( which the SYSTEM principal would not be ), your Invoke-RestMethod call should work. We use this same Cmdlet in a significant portion of our own Catalog Worklets.

 

If you’d like to share more code relative to the Invoke-RestMethod call, I’d be happy to provide a second set of eyes to see if there’s a surrounding issue.

 

Hope this helps!

 

Anthony M.

 

Reply


Terms & ConditionsCookie settings