Roles not applying - SAML2 Entra ID Authentication

Product: PowerShell Universal
Version: 5.5.4

Hi,
I have just setup SAML2 and I can authenticate in however it states I have no permissions. I have followed the SAMl2 guide and when I have assigned the Administrator Role to my Entra Group ID and Type, I can see it states group ID under ‘My Identity’. It states this as my role but not with any other account I login with.

I have no idea why it wont give me the admin role.

Can anyone provide some assistance, we have never got this working.

image|670x500

I have tried with the URL - http://schemas.microsoft.com/ws/2008/06/identity/claims/groups and groups

I had a similar issue with Windows Authentication. I was using a custom role that inherits another role (nested role).
Make sure you review this section of the docs - https://docs.powershelluniversal.com/security/security#users-with-many-groups

Also, I noticed some strange behavior with ‘External Accounts’ and role assignments. When a user signs in via Windows SSO and receives their role through claim assignment, it does not list this role on the Identities page, however the user does receive the role. I’m not sure if this is a visual bug or intended, but I spent a day diagnosing this. You should verify this by using a secondary account, giving yourself permission to the admin page, and viewing your roles under ‘My Identity’

Hey,
Thank you for this, I have tried that and it did not work.
Just for awareness, my Entra Enterprise App is set to only send the groups assigned to the app which is just 1 group at the moment.

I do not get any of those errors outlined.

Hi @JANID,

just to be sure: how do you map the Group Id to the role in PSU?
Are you sure that the claim is configured in the right way (whether role or group claim, type like GUID, sAMAccountName, …) besides needs to be assigned to the app?
Do you have some screenshot?
We map the roles directly in the roles’ .ps1 file to be more flexible.

Best,
Matthias

1 Like

Hi @blindzero
Are you able to provide me a screenshot on how you map the roles in the roles.ps1 file?

I use the GUI and followed the doc for the Entra ID portion. I am sure im doing something wrong as I do not see many people with this issue and its never worked for me.

Screenshot of the GUI, I have santised the claim value.

Roles.PS1 Administrator Line Entry (sanitised) -

New-PSURole -Name “Administrator” -Description “Administrators can manage settings, create and edit any entity and view all the entities with PowerShell Universal.” -ClaimType “groups” -ClaimValue “98fe64243234252-56f7-4235-b532342422-8242342d12782de322342e” -DefaultRoute “/admin”

Hi @JANID

for admins we have in roles.ps1

New-PSURole -Name "Administrator" -Description "Administrators can manage settings, create and edit any entity and view all the entities with PowerShell Universal." -Policy {
    param(
        [Security.ClaimsPrincipal]$User
    )

    # Check role claim for OpenIDC SSO w/Entra OR On-Prem Windows SSO Groups (non-nested)
    if (
    ($User.HasClaim('http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid', 'S-1-5-00-000000000-0000000000-0000000000-0000')) -or ($User.HasClaim('http://schemas.microsoft.com/ws/2008/06/identity/claims/role', 'ITAC (PSU) Admins'))
    ) {
        $true
    }
} 

Where ITAC (PSU) Admins is the name of the Azure group - we configured not to use the GUID but name.

Best,
Matthias

Hey,
Thank you for this.
I tried this and it still did not give me the role.
Its weird because it shows the Object ID as my role which only ever appears if its assigned to a role within PSU and the Azure App. I have tried with a account that has less than 10 groups as well.

I have a ticket in with support, but I have had a few in regards to this where documention needed to be updated and with the time difference (us being UK and them being US) made it difficult to keep on top of support.

Again, I have followed the docs for the Entra setup start to finish so I am not sure where I am going wrong.

Ill update this we come to a resolution within the support ticket with the fix.

Thanks all!

I made an app page that shows me all claims of the currently logged on user, just to be sure.

Then I made script in roles.ps1 that maps group ID and/or email addresses to roles, based on config files.
The config files are plain text and can be edited with another page script.

I did that, because the GUI (back then, no idea how it evolved) could not map multiple roles to a group id.

In Azure I have:

  • added user.groups claim
  • Groups assigned to the application
  • source attribute: GROUP ID

Hey,
My Azure is setup the same way.
Do you have details on what you did to force the administrator role mapping when my user logs in with and is part of the relevant Azure Group?

From what I can gather, it seems a lot of people have been using CLI to fix issues. I have just been following the docs on their WIKi.

Appreciate you taking the time to comment on this. Im stuck in a hard place on how much time I should spend trying to troubleshoot this within work time when I have other work to complete. If it doesn’t work and we cannot get support to fix it, we may just have to drop it from going live which we rather not do.

@deroppi

I have a feeling my issue isnt mapping the role but the platform giving me the role its meant to. Something seems to be missing from this.

The code I have is right, it just wont give me what I need.

Not easy to explain here in the forum.
And I can’t just copy paste scripts, need to get rid of anything company related first…

So Azure gives me email address adn groupid, besides other things.
I verified by showing all claims in a simple app page.

In PSU I have created 4 custom roles that we need.
In the admin GUI I added the same code for each role, just working of different config files.
It works the same way for admin.

(shortened and stripped script, might not run if you copy/paste, just an idea)

param(
    [Security.ClaimsPrincipal]$User
)

# this reads a text file with all group IDs and emails I allow for a role
# strips empty lines and comments
$allowed += (Get-Content (Join-Path $repository $allowedFile) | ? { $_ -notmatch "^\s*#|^\s*$" }).trim()

# add all email addresses to EMAILs array
$EMAILs = ($allowed | ? { $_ -match "@" }).trim()

# add all group IDs to groups array
$groups = $allowed | ? { $_ -match "[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}" }

# add all azure provided group claims to claimsGroups array
$claimsGroups = ($User.Claims | ? { $_.type -match "identity/claims/groups" }).value

# this is the value the code will drop at the end of the script. 
# if a script ends with TRUE, the user is seen as allowed.
$flag = $false
  
# if the logged on user matches set tthe flag to TRUE
if ($user.identity.name -in $EMAILs) {
    $flag = $true
} 

# now check if ayn of the azure provided group IDs match the group IDs we want to allow
$trueGroups = Compare-Object -ReferenceObject $groups -DifferenceObject $claimsGroups -IncludeEqual -ExcludeDifferent
$outcome = ($trueGroups.sideindicator | sort -Unique)

if ( $outcome -eq "==") {
    $flag = $true
}

# end the script with simply returning the flag value
$flag   


So the above code (plus some logging I left out here) is set in the admin GUI for each role including admin.
For each role there is a text file containing the allowed group IDs and/or emails.

This works nicely.

1 Like

To test whether I receive the right claims from azure, I simply show all relevant items in a table.

$columns=@(
    New-UDTableColumn -Property Name
    New-UDTableColumn -Property Value
)


$var=@()
$var+=@{name="User"; value=$User}
$var+=@{name="Roles"; value=$Roles -join ","}
$var+=@{name="RemoteIpAddress"; value=$RemoteIpAddress}
$var+=@{name="RemotePort"; value=$RemotePort}

$var+=@{name="PSUComputerName"; value=$PSUComputerName}

$var+=@{name="$($ClaimsPrincipal.identity)"; value=($ClaimsPrincipal.identity.name)}

foreach($item in $ClaimsPrincipal.claims) {
    $var+=@{name="$( ($item.type -split "claims")[-1] )"; value="$($item.value)" }
}

New-UDTable -Data $var -Columns $columns -Title "logged on user account claims"

I have figured this out now.
The guide that states ‘If you select Groups assigned to the application, ensure that you check the Emit groups as role claims value. This setting requires a paid Entra ID plan.’

I unchecked this and it worked correctly. The URL ended in /roles not /groups when this was checked.

2 Likes