With approximately 60–70% of administrators proficient in PowerShell compared to other scripting languages (such as Bash), our Professional Services team identified that focusing on PowerShell execution would deliver the highest value to customers. This capability helps organizations reduce their privileged access footprint and provides valuable functionality for our Professional and Expert Services teams during implementation projects.
This release introduces the new PowerShell Script Execution capability to Privileged Task Automation (PTA), enabling organizations to securely delegate PowerShell script execution to non-privileged users while maintaining proper controls.
Problem
Organizations struggle to securely delegate PowerShell script execution to non-privileged users while maintaining control and auditability. Current solutions often require granting excessive standing privileges or involve time-consuming manual processes by privileged administrators, creating security risks and operational bottlenecks.
Solution
Our new PowerShell Script Execution capability in PTA allows customers to:
Execute PowerShell scripts securely through workflows without granting standing administrative privileges
Automate common IT operations like Exchange mailbox management, Active Directory operations, and system configurations
Integrate PowerShell automation directly into joiner/leaver workflows and incident response processes
Support multiple argument types and structured output formats for complex automation scenarios
Key Use Cases:
Joiner Workflows: When someone joins the organization, workflows can now invoke PowerShell scripts to set up home directories with appropriate permissions, configure device encryption, register devices with InTune or JAMF, and perform other setup tasks that traditionally required manual administrator intervention.
Leaver Workflows: When someone leaves the organization, PowerShell scripts can automatically archive home directories, set legal holds for executives or insiders, and perform cleanup tasks while the main workflow handles access removal and notifications.
Exchange Administration: Create and manage different types of mailboxes (room, shared, remote) through automated workflows without requiring Exchange admin privileges for end users.
Active Directory Operations: Perform cross-domain operations and user management tasks through secure, controlled script execution.
Who is affected?
Business and Business+
Primary Customer Profiles:
IT Operations teams managing Windows environments and Active Directory
Exchange administrators who need to automate mailbox management
Security teams implementing automated incident response
Organizations with complex joiner/leaver processes requiring PowerShell automation
Customer segments most likely to benefit:
Mid to large enterprises with significant Windows infrastructure.
Organizations currently struggling with privileged access management for PowerShell scripts.
Teams looking to reduce manual administrative overhead.
Action Required
For existing Workflows admins/users: Review your current automation processes to identify opportunities where PowerShell script execution could replace manual administrative tasks or reduce standing privileges.
For new implementations: Work with your Professional Services engineer or Solution Engineer to identify high-value PowerShell automation use cases during your next implementation planning session.
As with all Windows Server Actions in PTA, a VA Cluster is required to execute the PowerShell script remotely.
Important Dates
General Availability: Target September 19, 2025
Additional Resources
Documentation: PowerShell Script Execution will be documented in our Workflows section
Support: Standard support channels will handle PowerShell execution questions
This goes life today?! On a Friday no less? No prerelease in sandbox environments allowing us to test for major bugs or security vulnerabilities before this gets deployed in production?
There is not even documentation available yet? It will be deployed before there is documentation available?
Can you please add screenshots in your announcement next time? Does this relate to the workflows component of SailPoint where we can have an action called “run power shell script”? Or is this not related to workflows at all? In which case I think you are using pretty ambiguous terms.
Yes, it has gone live today. We conducted an extensive early access/closed preview for a few months, receiving great feedback. You are welcome to test the capability within your sandbox environment before deploying it into production.
Documentation is available under the “Windows Server” portion of the Privileged Task Automation Actions: Workflow Actions - SailPoint Identity Services - see the “Execution PowerShell Script” portion.
Here is a screenshot of the location, with regard to the Action and corresponding Command:
Probably would have been good to mention this is part of workflow Privileged Task Automation which requires a special VA type and is completely separate from IQService PowerShell execution.
I am super excited my this. The prospects are huge and it raises the extensibility of the ISC to another level. I have worked extensively with Azure PS runbooks as webhooks to be called from the ISC workflows but its a call out to another system, no back and fort banter. I have also worked extensively with Azure logic apps where a PS card can be integrated and there is a 2 way communication between the cards via inbound parameters and Json output. I can see these communication tools are there in the ISC PS card. Awesome!
I will be testing and will post KBs on using the card to overcome ISC limitations and spice up your workflow.
Love this. I had originally brought this up with some folks at Navigate a couple of years ago, and while I don’t have a use case for it right now myself, really glad to see this functionality added. Thank you all!
Was anyone able to get this workflow to execute a PS script that uses AD cmdlets like New-ADUser ?
I was able to call the PS script from the Windows server action, but noticed that it doesn’t execute cmdlets like New-ADUser. It looks to be an issue with the context in which the script runs. When the script runs locally on the server using PowerShell ISE or PS console, it runs fine in an interactive environment. But when the same script is launched from the ISC workflow, it runs with Interactive=false.
Has anyone been able to get past this issue? Any inputs would be appreciated.
I think we need to get some documentation on the limits of what script items are supported and documentation around parameters that we can pass into the script.
Currently it seems like, unless you select “Select Variable”, the parameters you set are static. Which is arguably useless because static parameters can just be hard coded into the script.
Could someone please clarify which port openings are required in this case?
To execute a PowerShell script against a Windows Server, I assume that port 5985 (HTTP) and 5986 (HTTPS) for WinRM need to be open. The connection is made to a standard Windows Server?
Are there any additional ports required, for example, to support authentication to the server itself?
I’m currently encountering the following issue:
Failed to invoke PAG connector command
{"result":null,"warnings":null,"error":{"detailCode":"403 Authorization Failed","message":{"locale":"en-US","localeOrigin":"DEFAULT","text":"Authentication failed."}}}
Any guidance on the necessary network or authentication configuration would be appreciated.
Hi @surjithsudhakaran ,
Were you able to run commands like Get-ADUser? I’ve configured the “Windows Server” to “Execute Powershell” with connection address as IQService Server Box Hostname and username and password as the IQService Service account used in AD source, the powershell script has commands like Get-ADUser and Set-ADuser but it errors out with this “unable to contact the server, this maybe because this server does not exist, it is currently down or it does not have AD webservices running”
Although the same script successfully executes “Get-ADUser” when I login to IQService Server Box and execute the script
All the workflow tasks are consumed from the Regular Virtual appliance cluster, and when it hits a privileged task, it delegates this specific task to the Privileged Access Gateway cluster. Which means, that the regular virtual appliances needs to be able to connect to PAG..
In my case, the regular virtual appliance cluster is on prem, and the PAG is on Azure, which made the 2 clusters not to be reachable or coordinate tasks among them.
The documentation fails to inform that, and to inform what ports need to be open between the regular and the privileged cluster. I assume is port 22, but I’m still investigating.
Hi @rpriya I was able to get this working. When using NTLM authentication to run PowerShell scripts with AD cmdlets, we kept running into the double-hop issue. To fix this, we had to switch to Kerberos based authentication. Even with Kerberos, the format of the details is strictly enforced and this is not clear in the documentation.
Ensure the KDC hostname and REALM are valid. KDC realm will be the Active directory domain name. (e.g. COMPANY.COM). This has to be in uppercase.
When specifying the username to connect to Windows server, use only the username. Do not include domain\ or user@domain.
We initially tried including the domain but kept getting “KDC_ERR_C_PRINCIPAL_UNKNOWN Client not found in Kerberos database” error.
When KDC realm is specified, SailPoint automatically appends the domain. Once we removed the domain name from the authentication details, it worked fine.
