Hey everyone, I am working on building out an integration with one of our internal systems and Netwrix Privilege Secure and came across an interesting dilemma. I have a custom PowerShell action that will query the remote systems API and initiate a syn to update a users permissions, but want to keep the API credentials stored within Netwrix as a website credential. The issue is, I don’t see any way to pull other credentials from within the custom PowerShell activity. Calls to both Get-SbPAMCredential, and Invoke-SbPamRest return with 403 forbidden from the activity context, and there doesn’t seem to be any other way I see to work around this. Has anyone else faced this issue and managed to work around it? Would be great to get some other perspectives on this.
Hi David,
403 is a permissions issue. Are you using an app role or user role? App role should work. If user, it has to be an admin with 2fa. Since you are trying to automate and can’t interactively enter the 2fa, you have to turn it off in the GUI, but it still needs to make the 2fa call after login and just use a dummy variable like 000000
Billy
Well this is from the custom PowerShell step within an activity, so I am not sure what access rights the token associated has. I can get the command to work outside of the custom PowerShell step and can do what you describe, but from within the custom activity step, I see no way to access the credential within the scope of the token used for custom PowerShell scripts.
I see. I’ll have to ask engineering what role/account is used in that case and if there is a method.
I appreciate that! It would definitely make things easier to be able to keep an API key within NPS as a credential and use that within custom PowerShell activity steps. That way the key only needs to be rotated in one location rather than a collection of scripts. If it is not currently possible I will open an idea post for it since it would definetly add value when building custom integrations.
The engineers sent me this. If that doesn’t help, we may need to talk directly.
Accessing Stored Credentials from a Custom PowerShell Activity
Netwrix Privilege Secure — Community Reference — Prepared for Billy VanCannon — June 2026
Note: This document addresses a community question about 403 Forbidden errors when calling
Get-SbPAMCredentialandInvoke-SbPamRestfrom within a custom NPS PowerShell activity, when trying to retrieve a website credential stored in Netwrix Privilege Secure.
Why the 403 Happens
There are two distinct sets of cmdlets with the same names that behave differently depending on context:
- The SbPAMAPI PowerShell module (external, installed on a workstation) requires a token with
isMFA = true. - The built-in action module (loaded automatically inside the ActionService runspace) uses the ActionService’s App token, which bypasses MFA requirements entirely.
When running inside a custom action, the injected token ($SbPAMRestApiToken) is an AppToken issued to the ActionService. It does not carry the isMFA claim, so calls made through the external SbPAMAPI module will return 403.
Option 1 — Simplest: Use the Built-in Action Context
If the custom PowerShell action is running inside the NPS ActionService, no import is needed. The ActionService automatically loads its own module and injects the following variables into every runspace:
| Variable | Description |
|---|---|
$SbPAMRestApiToken |
AppToken for the ActionService (App role, bypasses MFA checks) |
$SbPAMRestApiUri |
Base URL of the NPS WebAPI |
$SbPAMRestRefreshToken |
Used for automatic token renewal |
$ActionQueueActionId |
GUID of the current action |
| Action parameters | Any parameters defined on the action template |
Simply call the built-in cmdlet directly — no import, no authentication setup:
# Pass the website credential's managed account GUID as an action parameter
# It will be available as a variable (e.g. $WebsiteCredentialId)
$cred = Get-SbPAMCredential -Id $WebsiteCredentialId -showPassword $true
# Use the password in your API call
$headers = @{ Authorization = "Bearer $($cred.Password)" }
Invoke-RestMethod -Uri "https://internal-system/api/sync" -Headers $headers
Recommendation: For actions running inside NPS, this is the right approach. The App token already has broad credential access and bypasses all MFA policy checks. No certificates, no credential management, no extra setup.
Option 2 — Application User Token (External Scripts / More Control)
An application user is a purpose-built NPS account type (AccountType = Application) designed for unattended automation. It authenticates via an X.509 certificate and the issued token carries isMFA = true and Role = App — allowing it to call all protected API endpoints without MFA prompts.
Setup (one-time, requires admin):
- Create the application user account via
POST /api/v1/ManagedAccount/CreateApplicationUser - Provision an X.509 certificate and register its serial number on the account
Usage:
$cert = Get-SbPAMCertificate -CertSerialNumber $AppUserCertSerial
$appCreds = New-Object PSCredential(
$AppUserName,
(ConvertTo-SecureString $AppToken -AsPlainText -Force)
)
$token = Get-SbPAMAppUserToken -Certificate $cert -Credentials $appCreds -Uri $SbPAMRestApiUri
$cred = Get-SbPAMCredential -Token $token -CredentialName "MyWebsiteCred" -Uri $SbPAMRestApiUri
Best suited for external automation: scheduled tasks, CI/CD pipelines, scripts running outside of NPS.
Option 3 — Interactive User Token with Automated MFA
You can authenticate as a regular admin user and automate the TOTP step using Get-SbPAMUserToken with a -UserSecret (TOTP seed). If 2FA is disabled on the account in the GUI, a dummy code can be passed.
$token = Get-SbPAMUserToken `
-Credentials $adminCreds `
-UserSecret $totpSecret `
-Uri $SbPAMRestApiUri
$cred = Get-SbPAMCredential -Token $token -CredentialName "MyWebsiteCred" -Uri $SbPAMRestApiUri
This works but is the most fragile option — use only if Options 1 or 2 are not viable.
Comparison Summary
| Approach | MFA Required | Setup Complexity | Best For |
|---|---|---|---|
Built-in action context ($SbPAMRestApiToken) |
No | None | Custom actions running inside NPS ActionService |
| Application user token | No (cert-based) | Moderate (cert provisioning) | External scripts, scheduled automation, CI/CD |
| Interactive user token | Yes (TOTP or disabled) | High | One-off or interactive use only |
That’s great information! Thank you for the help. As a heads up, it looks like the version of Get-SbPAMCredential that is used by the action service does not accept a showPassword parameter and always returns the password.