Custom PowerShell Action Permissions

I’m just posting as I have come to a realization that I can’t find any documentation on what permission level custom PowerShell actions run at. More specifically, when discussing the possibility of creating a custom PowerShell action to check for any duplicated activities, I realized I have no idea what level of authorization the API token set in the SbPAMRestApiToken variable is. From some quick testing it seems to not be an admin token, but it can also do more than a user would be able to so I am interested if anyone can shine some light on what level of access I should expect to have in a custom action step.

Additionally, it seems some of the SbPAMAPI PowerShell modules are overridden with different, undocumented functions. One such example being Get-SbPAMActivitySession. When using the SbPAMAPI module on a regular machine, you are required to enter a URI, Token, and status parameter; however, stating a URI and Token within a custom PowerShell step will throw an error resolving the parameter. Can I get confirmation if this is expected behavior and if so, is there documentation on the specific SbPAMAPI functions that ARE loaded in the custom PowerShell step?

Hello David,

Thank you for the question.

  1. The role assigned to the API Token given to the ActionService is “App” that has less permissions than an Admin in some cases and more in others. We still need to create a comprehensive document on the differences.
  2. The PowerShell module loaded by the ActionService is different from the PowerShell module we ship. The quick answer is that it leverages variables that we set from within the Windows Service that hosts the PowerShell host. The longer version is that because the ActionService uses a token with a role an interactive user can’t use, we decided to create a separate module.

Documentation on the internal modules is certainly something we need to produce. And I encourage you to add this as an idea so we can get this prioritized!

Thanks again for being a part of our community!

And here is the signature of the function you asked about:

function Get-SbPAMActivitySession {
	param(
		[Parameter(Mandatory = $false)]
		[Guid]$Id = [Guid]::Empty,
		[Parameter(Mandatory = $false)]
		[string]$RestApiUri = $Global:SbPAMRestApiUri,
		[Parameter(Mandatory = $false)]
		[string]$RestApiToken = $Global:SbPAMRestApiToken,
		[Parameter(Mandatory = $false)]
		[string]$Status = $null,
		[Parameter(Mandatory = $false)]
		[Guid]$TargetId = [Guid]::Empty,
		[Parameter(Mandatory = $false)]
		[Guid]$TargetUserId = [Guid]::Empty
	)

NOTE: Any parameters that have default values with $Global::xxx can be safely omitted. We generally leave those out in our internal calls because they are added to the environment by the Windows Service.

3 Likes

Thanks Kevin! You always have just the answer I’m looking for.

To follow up on a few of your points, can you confirm that the ActionService is calling the PowerShell code stored in

%programFiles%\Stealthbits\PAM\ActionServiceWorker\Powershell

If so, it makes it easy enough for me to simply go look for myself what differences exist between the shipped API module and what is running in the custom PowerShell action. Also, don’t worry, every opportunity I have had to speak with the Netwrix team I have begged for more, and more descriptive documentation. If you believe adding it as an idea here will help further, I will be more than happy to go create the post. One last thing on this topic, should this app token level of authorization be able to pull all activity sessions (active and historical)? Currently when calling Get-SbPAMActivitySession with a status as shown below, I get garbage data back (shown beneath that) instead of any returned data. Not sure if this is a bug, or a permissions issue disguised as a bug haha. I know the API endpoint that is getting called works, since I can query it from the SbPAMAPI module without issue with an admin token.

Command called (on build 25.8.15002.0)


$AllSessions = Get-SbPAMActivitySession -Status Active

Add-SbPAMActionLog -Type Info -Message "All Sessions: $AllSessions"

Raw HTML returned (sorry for formatting, it was pulled from the activity log CSV)

"All Sessions: <!doctype html>\n<html lang=\"en\">\n    <head>\n        <meta charset=\"utf-8\" />\n        <meta\n            name=\"viewport\"\n            content=\"width=device-width, initial-scale=1, shrink-to-fit=no\"\n        />\n        <base href=\"/\" />\n\n        <meta\n            name=\"apple-mobile-web-app-title\"\n            content=\"Netwrix Privilege Secure\"\n        />\n        <meta name=\"application-name\" content=\"Netwrix Privilege Secure\" />\n        <meta name=\"theme-color\" content=\"#ffffff\" />\n        <link rel=\"shortcut icon\" href=\"/nwx-favicon.ico\" />\n\n        <title>Netwrix Privilege Secure</title>\n      <script type=\"module\" crossorigin src=\"/assets/index-D_aIEOYZ.js\"></script>\n      <link rel=\"stylesheet\" crossorigin href=\"/assets/index-cgNAe-rv.css\">\n    </head>\n    <body>\n        <noscript> You need to enable JavaScript to run this app. </noscript>\n        <script>\n            var iePath = \"/ie/index.htm\";\n            var ua = window.navigator.userAgent;\n            var msie = ua.indexOf(\"MSIE \");\n            var trident = ua.indexOf(\"Trident/\");\n            var isIE = msie > 0 || trident > 0;\n            if (isIE) window.location = iePath;\n        </script>\n        <div id=\"root\"></div>\n    </body>\n</html>\n",7,"2025-08-28T15:12:53.843239Z","25.8.15002.0","7"

Again, thanks for your quick and concise response Kevin!

1 Like

Hello David,

I was just looking at the method you are using and it appears that method has a bug. Internally we never use those arguments. At some point we deprecated that specific endpoint. You can find the number of activity sessions a specific user has open, but the App role can’t enumerate all the active sessions.

so the following will work

$activitySessionCount = Get-SbPAMActivitySessionCount -Status "active" -TargetUserId $userId

But this will yield an error

Get-SbPAMActivitySession -Status "active"

We try to limit what the App role can do to prevent a backdoor to viewing information that shouldn’t be allowed.

And to answer your first question about submitting the idea, I think that is the best way to get your request prioritized and tracked by the Product team. The more people that want a feature the more likely it will get prioritized and passed on to the development team.

2 Likes

Thanks for looking into that Kevin. At your advice I have created an idea post for improved documentation. I fully understand the reason to limit the access scope of the app token that the application uses for custom actions. Hopefully the access scope of the app tokens can be documented because I think once there is more documentation of the modules in place and access rights associated with custom actions, we’ll see some more people creating cool and useful custom actions within the platform.

3 Likes

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.