dylegrand

Hello,

Yes, I can confirm that the issue has been resolved in the latest version.

Thank you

------------------------------------------------------------

Product: PowerShell Universal

Version: 2026.3.3

Hosting: IIS

OS: Windows Server 2025

Database: SQL Server

------------------------------------------------------------

In PSU, it is possible to create an application that runs on PowerShell 7. It will start up and display the application as follows:

New-UDApp -Content { 'Hello, everyone!' }

However, if the environment is changed to "Integrated" and then switched back to PowerShell 7, the application remains stuck in a "Deployed" state, and subsequently, no one can log in to PSU using a domain account.

The following error message appears:

Status(StatusCode="Unavailable", Detail="failed to connect to all addresses", DebugException="Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1793109706.532000000","description":"Failed to pick subchannel","file":"..\..\..\src\core\ext\filters\client_channel\client_channel.cc","file_line":3218,"referenced_errors":[{"created":"@1793109706.532000000","description":"failed to connect to all addresses","file":"..\..\..\src\core\lib\transport\error_utils.cc","file_line":165,"grpc_status":14}]}")

The issue persists even after restarting the IIS service; only the local PSU admin user is able to log in.

To restore the service, one must disable the application's automatic startup, switch it back to "Integrated," and then restart the IIS service once more.

Furthermore, it is not possible to run an application on PowerShell 7 while also executing it as a GMSA (Group Managed Service Account).

Thank you in advance for your expertise.

Hi,

Thanks for the workaround. It also resolves the issue on my end when setting the permissions in `roles.ps1`.

To answer your question, the `automation/read` permission had not been removed at the time of the test.

Thank you very much for your support.

------------------------------------------------------------

Product: PowerShell Universal

Version: 2026.3.3

Hosting: IIS

OS: Windows Server 2025

Database: SQL Server

------------------------------------------------------------

CONTEXT

The script is not run directly by the user. The user calls an authenticated API endpoint, and it is the endpoint code that runs the script with Invoke-PSUScript:

User (AD group member, role DLG-PSU_2424)

-> calls API endpoint (Authentication enabled, restricted to DLG-PSU_2424)

-> endpoint code runs Invoke-PSUScript

-> script Add-UserToADGroup.ps1

Endpoint code (simplified):

param($Param1)

Invoke-PSUScript -Name '<Folder>\Add-UserToADGroup\Add-UserToADGroup.ps1' -Parameters $Param -Wait

The endpoint itself is reachable and executes correctly: the access denied error is raised by the Invoke-PSUScript call inside the endpoint. Replacing the Invoke-PSUScript line with $ClaimsPrincipal returns the expected identity, role and permissions (see EVIDENCE below), and replacing it with Get-PSUScript on the same script succeeds.

------------------------------------------------------------

SUMMARY

When a custom role is granted scoped permissions on a single script (or even the global automation.scripts/execute permission), calling Invoke-PSUScript from an API endpoint fails with:

"Permission denied. The role specified does not have access to this resource"

Get-PSUScript on the same script, from the same endpoint, succeeds with the same role, which shows that the scoped permission is matched correctly for read access. The call only succeeds when a parent-scope permission is added to the role: either automation/read or automation/execute. Both grant access to all automation resources, which defeats folder/script-level delegation.

EXPECTED BEHAVIOR

A role with automation.scripts/view + read + execute permissions scoped to a single script should be able to run that script through Invoke-PSUScript from an API endpoint, without needing access to the whole automation scope.

ACTUAL BEHAVIOR

Invoke-PSUScript, called from the API endpoint, is denied unless the role has automation/read or automation/execute.

------------------------------------------------------------

CONFIGURATION

Role: DLG-PSU_2424

- Claim type: http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid

- Claim value: AD group SID

- Role permissions: automation.scripts/view

Scoped permissions (created from the script's Permissions dialog, assigned to the role):

- automation.scripts.<Folder>\Add-UserToADGroup\Add-UserToADGroup.ps1/read

- automation.scripts.<Folder>\Add-UserToADGroup\Add-UserToADGroup.ps1/execute

API endpoint:

- Authentication: enabled

- Roles: DLG-PSU_2424, DLG-PSU_Administrator

- Execution roles: DLG-PSU_2424, DLG-PSU_Administrator

------------------------------------------------------------

EVIDENCE: CLAIMS ARE CORRECTLY RESOLVED

Returning $ClaimsPrincipal from the endpoint (called by a member of the AD group) shows:

Type : http://schemas.microsoft.com/ws/2008/06/identity/claims/role

Value : DLG-PSU_2424

Type : PSUPermission

Value : automation.scripts/view

Type : PSUPermission

Value : automation.scripts.<Folder>\\Add-UserToADGroup\\Add-UserToADGroup.ps1(.*)/read

Type : PSUPermission

Value : automation.scripts.<Folder>\\Add-UserToADGroup\\Add-UserToADGroup.ps1(.*)/execute

The role and permissions are correctly present in the identity. Cached claims were ruled out (new sign-in after every change).

------------------------------------------------------------

STEPS TO REPRODUCE

1. Create a custom role with only automation.scripts/view.

2. Create a script in a subfolder, open its Permissions dialog and grant read and execute to the role.

3. Create an authenticated API endpoint restricted to that role, containing:

Get-PSUScript -Name '<Folder>\Add-UserToADGroup\Add-UserToADGroup.ps1' # Test A

Invoke-PSUScript -Name '<Folder>\Add-UserToADGroup\Add-UserToADGroup.ps1' # Test B

4. Call the endpoint as a user holding only that role.

------------------------------------------------------------

TEST MATRIX (all tests run from inside the API endpoint)

Additional permissions on the role Get-PSUScript Invoke-PSUScript

-------------------------------------------------------------------------------------------

1. none OK DENIED

2. none, with -Wait OK DENIED

3. none, with -Integrated OK DENIED

4. automation.jobs/read OK DENIED

5. automation.scripts/execute + automation.jobs/create OK DENIED

6. automation.environments/read OK DENIED

7. automation.jobs/* OK DENIED

8. automation.computers/read OK DENIED

9. automation/read OK OK

10. automation/execute OK OK

11. automation/* OK OK

------------------------------------------------------------

ANALYSIS

- The scoped permission pattern is matched correctly for read (test A succeeds from the endpoint).

- The failure is not related to jobs, environments or computers (tests 4, 6 to 8).

- Even the global automation.scripts/execute is not sufficient (test 5).

- Any permission at the parent automation level, regardless of access type (read or execute), unlocks the call (tests 9 and 10).

This suggests that the authorization check performed by Invoke-PSUScript, when called from an API endpoint, evaluates a resource at the automation scope level instead of automation.scripts.<path>, so scoped permissions are never considered.

------------------------------------------------------------

IMPACT

Folder- and script-scoped delegation (as described in the Permissions documentation) cannot be used for scripts invoked from API endpoints. The only working workaround is granting automation/read or automation/execute, which exposes or allows execution of every script on the instance, including scripts running under privileged credentials.

Hello,

I would like to propose two enhancements that would significantly improve the developer experience and the quality of generated OpenAPI specifications.

1 Support Enumeration Values in OpenAPI / Swagger

Current Behavior

When defining an API input model, it is currently difficult or impossible to expose a list of allowed values as an OpenAPI enum.

For example:

enum ActionType {
  ADD
  REMOVE
}
 
[Documentation()]
class GroupMembershipRequest {
  [ActionType]$Action
}

Actualy the generated Swagger schema displays:

{
  "action": "string"
}

2 Separate Required Parameters by HTTP Method Within the Same Endpoint

Current Behavior

When documenting an endpoint that supports multiple HTTP methods (for example, GET and POST), the parameters apply to all methods.

Would it be possible to have an .INPUTS parameter that is conditional on the method?

Thank you in advance.

Hi,

I'm experiencing an authorization issue in PowerShell Universal in version 2026.3.2 that only occurs when using the built-in Test tool.

I have an API endpoint that starts an automation script using:

Invoke-PSUScript -Name "script.ps1" -Parameters @{Variable = $Variable} -Wait

The script is configured to run with the Administrator role.

When the endpoint is called externally using Invoke-RestMethod, everything works correctly and the script executes as expected.

However, when I use the Test feature from the PSU web interface, I receive the following error:

Permission denied. The role specified does not have access to this resource.

Has anyone encountered this behavior before?

Thanks!

Hello,

I have the same problem.

Have you found a solution?

Thanks.