Roles/Permissions assignment not working

I had similar issues when I started back then with a way lower version.

I created my own solution, bypassing any PSU automation.
An app page in my PRIV app that let admins define group-ids or email addresses matching roles,
and some code that needs go into the roles.ps1 for each role you have that assigns the proper roles for a user.

The roles code is here: (redacted, hopefully still readable, worked robust so far)

New-PSURole -Name "Local Common" -Policy {
    param(
        [Security.ClaimsPrincipal]$User
    )
    # policy file for roles
    # v1.5
    $localRole = "COMMON"
    #           ^^ set role here 

    $allowedFile = "allowed_$($localRole).txt"
    $syslog = @()
    $allowed = @( #dummy entries
        "mail@mail",
        "12345678-aaaa-bbbb-cccc-ffffffffffff"
    )
    $allowed += (Get-Content (Join-Path $repository $allowedFile) | ? { $_ -notmatch "^\s*#|^\s*$" }).trim()

    $mails = ($allowed | ? { $_ -match "@" }).trim()
    #                                    a6699aa7  -0XXb       -XXb8       -81XX       -31eXXXXXaae8
    $groups = $allowed | ? { $_ -match "[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}" }
    $claimsGroups = ($User.Claims | ? { $_.type -match "identity/claims/groups" }).value

    $syslog += "$($user.identity.name)"

    $flag = $false
    if ($user.identity.name -in $mails) {
        $flag = $true
        $syslog += "$($flag): $($user.identity.name)"
    }

    $trueGroups = Compare-Object -ReferenceObject $groups -DifferenceObject $claimsGroups -IncludeEqual -ExcludeDifferent
    $outcome = ($trueGroups.sideindicator | Sort-Object -Unique)
    if ( $outcome -eq "==") {
        $flag = $true
        $syslog += "$($flag): $($trueGroups.inputobject -join ',')"
    }

    if ( $flag ) {
        Write-PSULog -Feature "Roles" -Resource "Local $($localRole)" -Message $($syslog -join "|")
    }
    
    # return flag, true for role granted
    $flag
} 

Hello thomaslanger,

Thank you for the detailed explanation and screenshots. I also noted the additional report in this thread describing similar behavior in an older PSU version. At this point, however, I would like to confirm whether both reports have the same underlying cause before treating them as the same issue.

The first step is to separate role assignment from the permissions applied to the script.

Could you please provide the following?

* Your exact PowerShell Universal version and build.
* Does this behavior affect every member of the AD group mapped to the `execute` role, or only certain users?
* For one affected user, can you confirm which PSU roles are effectively assigned after Windows SSO authentication?
* After changing the role assignment, does signing out completely and signing back in change the result?

As an additional test, if possible, please temporarily assign the same `execute` role directly to a test Identity in PSU rather than obtaining it through the Windows SSO group mapping. Then sign out, sign back in, and check whether the assigned script becomes visible in the Portal.

This will help us determine whether the issue is related to the AD group / role evaluation or to the Portal and script permission configuration itself.

If you can also share the relevant sanitized definitions for the broad role and the `execute` role, that would help. We do not need the complete configuration.

Because this is a public forum, please sanitize all evidence before posting. Remove credentials, tokens, license keys, cookies, private keys, full connection strings, email addresses, usernames, customer data, tenant or account identifiers, internal domains, hostnames, IP addresses, and private URLs. Please do not upload unredacted HAR files, memory dumps, database backups, or complete configuration files to this public thread.

References:
https://docs.devolutions.net/powershell-universal/security/authorization
https://docs.devolutions.net/powershell-universal/security/enterprise-security/permissions
https://docs.devolutions.net/powershell-universal/security/enterprise-security/windows-sso

Best regards,
Ruben Tapia

@deroppi thank you for this - so you basically created your own Portal?

Ruben - thank you for your response.
* Your exact PowerShell Universal version and build. --> 2026.1.6
* Does this behavior affect every member of the AD group mapped to the `execute` role, or only certain users? --> all of them
* For one affected user, can you confirm which PSU roles are effectively assigned after Windows SSO authentication?
This is rather interesting - in order to obtain this information, I created a script outputting $UAJob to Json. For the user to be able to execute the script, I had to assign "All" - immediately the script was displayed in the Portal.


Here are the relevant parts of the $UAJob output. This is interesting, as obviously the AD groups are assigned correctly, however only the first one (dlg.******.infra01.PSU.All) seems to have any effect:

"Identity":  {
                     "Id":  72,
                     "Name":  "******\\ts77184",
                     "Source":  "Git",
                     "RoleName":  null,
                     "Roles":  null,
                     "CredentialVault":  null,
                     "Password":  null,
                     "LocalAccount":  false,
                     "OldPassword":  null,
                     "Settings":  null,
                     "Theme":  "light",
                     "JobColumns":  null,
                     "JobStatuses":  null,
                     "PasswordLastSet":  null,
                     "System":  false,
                     "ExcludedScripts":  null,
                     "SelectedScripts":  null,
                     "DevolutionsAccount":  false
                 },
[...]
"Roles":  "dlg.******.infra01.PSU.All,dlg.******.infra01.PSU.******Infrastructure**.execute",
[...]
"ReadPermission":  "automation.scripts.Get-PSUVars.ps1/read",

As an additional test, if possible, please temporarily assign the same `execute` role directly to a test Identity in PSU rather than obtaining it through the Windows SSO group mapping. Then sign out, sign back in, and check whether the assigned script becomes visible in the Portal.
So I assigned to role directly to the Identity, which leads to nothing being displayed in the portal anymore:


* After changing the role assignment, does signing out completely and signing back in change the result? --> No, also signing off from the Workstation, Private Mode, ... does not change anything.

If you can also share the relevant sanitized definitions for the broad role and the `execute` role, that would help. We do not need the complete configuration. --> (I'm guessing what you mean is the relevant portions of the roles.ps1?)

New-PSURole -Name "dlg.******.infra01.PSU.All" -Description "Permissions for all users" -ClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid" -ClaimValue "S-*-*-**-**********-********-**********-******" -DefaultRoute "/portal" -Priority 99 
New-PSURole -Name "dlg.******.infra01.PSU.******Infrastructure**.execute" -Description "Users allowed to execute reporting Scripts in ****** Infrastructure (**) Folder" -ClaimType "http://schemas.micrsooft.com/ws/2008/06/identity/claims/groupsid" -ClaimValue "S-*-*-**-**********-********-**********-******" -DefaultRoute "/portal" -Priority 99 

I also did some tests with other users:

"Identity":  {
	 "Id":  73,
	 "Name":  "******\\*******",
	 "Source":  "Git",
	 "RoleName":  null,
	 "Roles":  null,
	 "CredentialVault":  null,
	 "Password":  null,
	 "LocalAccount":  false,
	 "OldPassword":  null,
	 "Settings":  null,
	 "Theme":  null,
	 "JobColumns":  null,
	 "JobStatuses":  null,
	 "PasswordLastSet":  null,
	 "System":  false,
	 "ExcludedScripts":  null,
	 "SelectedScripts":  null,
	 "DevolutionsAccount":  false
 },
[...]
"Roles":  "dlg.******.infra01.PSU.All,dlg.******.infra01.PSU.Operator,Operator",
[...]
"ReadPermission":  "automation.scripts.Get-PSUVars.ps1/read",

--> is able the execute the script in the Portal, has "Operator" permissions in the Admin console

"Identity":  {
	 "Id":  26,
	 "Name":  "******\\**********",
	 "Source":  "Git",
	 "RoleName":  null,
	 "Roles":  null,
	 "CredentialVault":  null,
	 "Password":  null,
	 "LocalAccount":  false,
	 "OldPassword":  null,
	 "Settings":  "{\"AppCodeByDefault\":false,\"ScriptListView\":null,\"SchedulesListView\":null,\"EditorSettings\":{\"ShowLineNumbers\":true,\"ShowWhitespace\":false,\"DisableAnalyzer\":false,\"Minimap\":false,\"Theme\":null},\"PageSize\":100,\"HideModuleHomePageCard\":false}",
	 "Theme":  null,
	 "JobColumns":  [
						"Id",
						"ScriptFullPath",
						"Status",
						"StatusDescription",
						"EndTime"
					],
	 "JobStatuses":  null,
	 "PasswordLastSet":  null,
	 "System":  false,
	 "ExcludedScripts":  [

						 ],
	 "SelectedScripts":  null,
	 "DevolutionsAccount":  false
 },
[...]
"Roles":  "dlg.******.infra01.PSU.admin,Administrator,dlg.******.infra01.PSU.All",
[...]
"ReadPermission":  "automation.scripts.Get-PSUVars.ps1/read",

--> is able to execute the script in the portal, has Admin permissions in the Admin Console

Should we open a support case on this matter?