Roles Not working 2026.3.0

avatar

I upgraded, and now i am locked out of the psu admin site with 'execute' only permissions.

All Comments (8)

avatar

2026-09-16 09:01:24.260 -05:00 [INF][] [ROLE 2026-09-16 09:01:24.258] role=Administrator user=myUSERNAME source=API message=lookup_failed error=Unable to resolve portal user 'myUSERNAME': You must be running this command in PowerShell Universal to use the integrated mode.
2026-09-16 09:01:24.276 -05:00 [INF][] [ROLE 2026-09-16 09:01:24.276] role=Execute user=myUSERNAME source=Policy message=member=true
2026-09-16 09:01:24.286 -05:00 [INF][] [ROLE 2026-09-16 09:01:24.286] role=Operator user=myUSERNAME source=Policy message=member=false
2026-09-16 09:01:24.294 -05:00 [INF][] [ROLE 2026-09-16 09:01:24.294] role=Reader user=myUSERNAME source=Policy message=member=true
2026-09-16 09:01:24.303 -05:00 [INF][] [ROLE 2026-09-16 09:01:24.303] role=User user=myUSERNAME source=Policy message=member=true
2026-09-16 09:01:24.444 -05:00 [INF][PowerShellUniversal.Authentication.ClaimsEvaluator] myUSERNAME is part of role Execute
2026-09-16 09:01:24.445 -05:00 [INF][PowerShellUniversal.Authentication.ClaimsEvaluator] myUSERNAME is part of role Reader
2026-09-16 09:01:24.445 -05:00 [INF][PowerShellUniversal.Authentication.ClaimsEvaluator] myUSERNAME is part of role User

avatar

@Matthew Morrow Can you share your role.ps1 file at all? I'm curious what cmdlets you are calling in it? This error is related to another issue but may be the actual root cause here.

Unable to resolve portal user 'myUSERNAME': You must be running this command in PowerShell Universal to use the integrated mode.

Adam Driscoll
PowerShell Expert and Software Architect at Devolutions

avatar

2026-09-16 09:01:24.260 -05:00 [INF][] [ROLE 2026-09-16 09:01:24.258] role=Administrator user=myUSERNAME source=API message=lookup_failed error=Unable to resolve portal user 'myUSERNAME': You must be running this command in PowerShell Universal to use the integrated mode.
2026-09-16 09:01:24.276 -05:00 [INF][] [ROLE 2026-09-16 09:01:24.276] role=Execute user=myUSERNAME source=Policy message=member=true
2026-09-16 09:01:24.286 -05:00 [INF][] [ROLE 2026-09-16 09:01:24.286] role=Operator user=myUSERNAME source=Policy message=member=false
2026-09-16 09:01:24.294 -05:00 [INF][] [ROLE 2026-09-16 09:01:24.294] role=Reader user=myUSERNAME source=Policy message=member=true
2026-09-16 09:01:24.303 -05:00 [INF][] [ROLE 2026-09-16 09:01:24.303] role=User user=myUSERNAME source=Policy message=member=true
2026-09-16 09:01:24.444 -05:00 [INF][PowerShellUniversal.Authentication.ClaimsEvaluator] myUSERNAME is part of role Execute
2026-09-16 09:01:24.445 -05:00 [INF][PowerShellUniversal.Authentication.ClaimsEvaluator] myUSERNAME is part of role Reader
2026-09-16 09:01:24.445 -05:00 [INF][PowerShellUniversal.Authentication.ClaimsEvaluator] myUSERNAME is part of role User

avatar
# PSU Upgrade: Administrator Role Lookup Failure

## Observed Error

After the PSU upgrade, the Administrator role lookup for `<DOMAIN>\<User>`
fails closed. The original host error text available in the trace is:

`[ROLE 2026-09-10 09:07:02.044] role=Administrator user=<DOMAIN>\<User> source=API message=lookup_failed error=api failure`

The original parameter-binding error text recorded during the investigation was:

`ParameterBindingException: A parameter cannot be found that matches parameter name 'Depth'.`

The older PSU version worked with the same Administrator role policy and user.

## Reproduction and Context

- The `Administrator` role policy resolves the user record before checking
  membership in `<AuthorizedGroup>`.
- The affected identity is `<DOMAIN>\<User>`.
- The failure started after a PSU upgrade; the old PSU version worked.
- The policy catches the resolver exception and returns `$false`.

## Confirmed Trace

The trace sequence is:

1. The Administrator policy entry is reached.
2. The policy invokes `Get-RoleUserRecord`.
3. The repository endpoint path is selected and the endpoint exists.
4. Endpoint invocation begins.
5. An exception occurs during endpoint execution.
6. No result normalization occurs.

The controlling code boundary is:

`& $EndpointPath -qUser $Username`

in `<RepositoryRoot>/Modules/<BackendModule>/1.0.0/Public/Get-RoleUserRecord.ps1`.

Verbatim host trace line:

```text
[ROLE 2026-09-10 09:07:02.044] role=Administrator user=<DOMAIN>\<User> source=API message=lookup_failed error=api failure
```

## Most Likely Failure Point

The most likely command is:

`$cachedADuser = Get-PSUCache -Key $cacheToken`

in `<RepositoryRoot>/.universal/endpoints/<App>/user.ps1`. The later `Get-PSUCache` call for
`cacheDomainController` (`Get-PSUCache -key cacheDomainController`) is the
second possibility. The current trace does not prove which of those two lines
failed.

## Root-Cause Hypothesis

Direct invocation of a PSU endpoint script from a role-policy runspace no longer
provides PSU integrated mode after the upgrade. As a result, integrated PSU
commands in the endpoint, such as `Get-PSUCache`, throw during execution.

## Impact

Administrator role lookup fails closed and returns `false`. The user is denied
Administrator access even when the directory or portal group membership is
valid.

## Recommended Next Diagnostic

Add `[DEBUG|...]` traces immediately before and after both `Get-PSUCache` calls
and before and after `New-PSUApiResponse` and `Set-PSUCache`. This will identify
the exact failing command. Alternatively, replace the direct endpoint invocation
with a supported PSU API or hosted seam that preserves the PSU integrated
execution context.

## Requested Vendor/Team Investigation

Please confirm whether the PSU upgrade changed the execution context used by
role-policy scriptblocks or direct endpoint-script invocation. Specifically,
verify whether PSU integrated commands are supported from this boundary and
identify the supported API or hosted seam for resolving a portal user from a
role policy.
avatar

@Adam Driscoll sent you an email with my code

avatar

Adam Driscoll
PowerShell Expert and Software Architect at Devolutions

avatar

@Adam Driscoll i agree that internal calls should work for the *-psucache functions

avatar

# Workaround
create Get-MyPSUCache and have it save .json files to the HD and manage said cache in the same way as the normal cmdlet