Role-Mapping for AD SSO Users not working

RubenT91 commented 6 months ago

Version

4.2.18

Severity

Low

Environment

msi

Steps to Reproduce

Set up PowerShell Universal with Active Directory Services Single Sign-On (KERBEROS) authentication. Configure roles in PowerShell Universal using New-PSURole cmdlet, mapping AD groups to roles like Administrator, Operator, Execute, Reader, and User. Create an authenticated API endpoint that invokes a PSU script (ShowBody.ps1) using Invoke-PSUScript. Invoke the API endpoint from PowerShell using Invoke-RestMethod with a JWT/Bearer token associated with a user belonging to the Execute role. Invoke the same API endpoint from a UI Form (PAGE with FORM) targeting the endpoint URL.

Expected behavior

When invoking the API endpoint from both PowerShell and the UI Form, the $UAJob.Roles within the PSU script should contain the appropriate roles (e.g., Execute) based on the user's AD group memberships. The script should be able to access and display the $SECRET:MyKey variable.

Actual behavior

When invoking the API endpoint from PowerShell, the $UAJob.Roles contains the Execute role, and the script can access and display the $SECRET:MyKey variable correctly.

However, when invoking the API endpoint from the UI Form, the $UAJob.Roles is empty, and the script cannot access or display the $SECRET:MyKey variable. The identity ($UAJob.Identity.Name) is correctly populated with the user's AD account (e.g., sc\sc406307as), but the roles are not mapped correctly.

Additional Environment data

PowerShell Universal version: 4.2.18 Environment: PowerShell Universal Server Authentication Flow: Active Directory Services Single Sign-On (KERBEROS) Role Mapping: Administrator: S-1-5-21-1757981266-583907252-###### Operator: S-1-5-21-1757981266-583907252--###### Reader: S-1-5-21-1757981266-583907252--###### Execute: S-1-5-21-1757981266-583907252--###### User: S-1-5-21-1757981266-583907252--###### Data added to ticket.

Screenshots/Animations

No response

git-posbis commented 6 months ago

Added some more info to the support ticket. https://support.ironmansoftware.com/portal/en/ticket/548223000032100001

PS C:\Users\SC406307AS> Get-PSUIdentity -UseDefaultCredentials -Name 'SC\sc406307as' Id : 2 Name : sc\sc406307as Source : Git Role : RoleName : Roles : CredentialVault : Password : LocalAccount : False OldPassword : Settings :

This is my SSO Identity and as you can see there is no Role assigned to it. If I do the same with the "admin" user it returns a role. Why is the Source "Git" ??? Anything wrong with my SSO Setup ?

It looks like a general issue of role mapping to AD SSO (Kerberos). So it is maybe not related to the FORM UI calling the endpoint but a more general problem.

My Role Mapping: New-PSURole -Name "Administrator" -Description "Administrators can manage settings, create and edit any entity and view all the entities with PowerShell Universal." -ClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid" -ClaimValue "S-1-5-21-1757981266-583907252-######"

I have a SPN set and SSO login works. I have Windows Login enabled

Authentication.ps1

Set-PSUAuthenticationMethod -Type "Form" -ScriptBlock { param( [PSCredential]$Credential )

New-PSUAuthenticationResult -ErrorMessage 'Bad username or password' } Set-PSUAuthenticationMethod -Type "Windows"

Regards, Oliver

adamdriscoll commented 5 months ago

This is not how JWT tokens work in this regard. When you create a JWT token, the roles that are assigned to that token are static at the time of the token's creation. It will not do a group membership lookup on the identity when the token is passed. It just uses the roles included in the token.

If you want to dynamically use the user's groups for your APIs, you will either need to implement forms or basic authentication to do the group lookup and return the claims or you will need to use Windows Auth with the web cmdlets.

Invoke-Restmethod http://myserver/myapi -UseDefaultAuthentication

git-posbis commented 5 months ago

Hi Adam

I think you misunderstood my case. I have enabled Single Sign On for my PSU Admin Console (Windows Authentication (Kerberos with registered SPN in my local AD)). I then map the groups SID to PSU Admin Roles using the following commands.

New-PSURole -Name "Administrator" -Description "Administrators can manage settings, create and edit any entity and view all the entities with PowerShell Universal." -ClaimType http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid -ClaimValue "S-1-5-21-1467889206-535997212-1644491937-96419" New-PSURole -Name "Operator" -Description "Operators have access to manage and execute scripts, create other entities within PowerShell Universal but cannot manage PowerShell Universal itself." -ClaimType http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid -ClaimValue "S-1-5-21-1467889206-535997212-1644491937-94739" New-PSURole -Name "Reader" -Description "Readers have read-only access to PowerShell Universal. They cannot make changes to any entity within the system." -ClaimType http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid -ClaimValue "S-1-5-21-1467889206-535997212-1644491937-96628" New-PSURole -Name "Execute" -Description "Execute scripts within PowerShell Universal." -ClaimType http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid -ClaimValue "S-1-5-21-1467889206-535997212-1644491937-94740" New-PSURole -Name "User" -Description "Does not have access to the admin console but can be assigned resources like APIs, scripts, dashboards and pages." -ClaimType http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid -ClaimValue "S-1-5-21-1467889206-535997212-1644491937-94741"

I would expect that a user who is a member of the AD-Group with the SID: S-1-5-21-1467889206-535997212-1644491937-96628 (Reader) accessing the Admin Console has only read capabilities. But this is not the case. He has full Admin rights. So, the mapping does not work.

That is my real problem.

What am I doing wrong ?

Regards, Oliver

From: Adam Driscoll @.> Sent: Montag, 10. Juni 2024 19:31 To: ironmansoftware/issues @.> Cc: Rehmann Oliver @.>; Comment @.> Subject: Re: [ironmansoftware/issues] Role-Mapping for AD SSO Users not working (Issue #3283)

EXTERNAL sender - do NOT click on links or attachments unless you expect them. EXTERNE Nachricht - NIE auf unerwartete Links oder Dateianhänge klicken.

This is not how JWT tokens work in this regard. When you create a JWT token, the roles that are assigned to that token are static at the time of the token's creation. It will not do a group membership lookup on the identity when the token is passed. It just uses the roles included in the token.

If you want to dynamically use the user's groups for your APIs, you will either need to implement forms or basic authentication to do the group lookup and return the claims or you will need to use Windows Auth with the web cmdlets.

Invoke-Restmethod http://myserver/myapi -UseDefaultAuthentication

- Reply to this email directly, view it on GitHubhttps://github.com/ironmansoftware/issues/issues/3283#issuecomment-2158927866, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BIPGQVR36N2XBUSTWSDB3A3ZGXPGFAVCNFSM6AAAAABGPQE3Y2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJYHEZDOOBWGY. You are receiving this because you commented.Message ID: @.***>

git-posbis commented 5 months ago

Hmmm….. I think I found the problem. It is working now.

If your users are members of more than about 40 groups you may experience problems logging in. This is due to size limits of the HTTP headers in IIS and Kestrel. The more groups a user is a member of, the more authorization claims they have and the large the header. You can increase the header limit for Kestrel by using the limits configuration in appsettings.json file. You will need to increase the header size. It is a value in bytes and defaults to 32kb.

{ "Kestrel": { "Endpoints": { "HTTP": { "Url": http://*:5000 } }, "Limits": { "MaxRequestHeadersTotalSize": 132768 }, "RedirectToHttps": "false" },

Our Standard Users have between 100-200 Claims 😉

Regards, Oliver

From: Adam Driscoll @.> Sent: Montag, 10. Juni 2024 19:31 To: ironmansoftware/issues @.> Cc: Rehmann Oliver @.>; Comment @.> Subject: Re: [ironmansoftware/issues] Role-Mapping for AD SSO Users not working (Issue #3283)

EXTERNAL sender - do NOT click on links or attachments unless you expect them. EXTERNE Nachricht - NIE auf unerwartete Links oder Dateianhänge klicken.

This is not how JWT tokens work in this regard. When you create a JWT token, the roles that are assigned to that token are static at the time of the token's creation. It will not do a group membership lookup on the identity when the token is passed. It just uses the roles included in the token.

If you want to dynamically use the user's groups for your APIs, you will either need to implement forms or basic authentication to do the group lookup and return the claims or you will need to use Windows Auth with the web cmdlets.

Invoke-Restmethod http://myserver/myapi -UseDefaultAuthentication

— Reply to this email directly, view it on GitHubhttps://github.com/ironmansoftware/issues/issues/3283#issuecomment-2158927866, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BIPGQVR36N2XBUSTWSDB3A3ZGXPGFAVCNFSM6AAAAABGPQE3Y2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJYHEZDOOBWGY. You are receiving this because you commented.Message ID: @.***>

ironmansoftware / powershell-universal