IIS Windows Authentication - RBAC?

Universal Dashboard Universal Dashboard Help
1

Relatively new to the UD world, and I’m working on understanding authorization and access rights for elements within UD setups. I’ve got an IIS setup going and Windows Auth is in place. I don’t see any information in the documentation referencing if further AD information on the logged in account is available. Can I control aspects of the UD setup from being accessed in an RBAC type functionality with this setup?

2

I believe it should be possible with Claims Authorization policies(here) as the AD User contains Name, GroupSid and other claims that sould be able to be matched. I have not yet been able to get it working myself, the issue I see at the moment is the AD claim types don’t seem to match with the examples (groupsid versus groups). If I can get it working I will add a sample

3

This looks to be the right direction. Being new to UD, is there a way I can play with a $user in an ISE session to see the data for working out the permissions? I saw the web terminal on 2.2 release notes, but wasn’t sure how to pull that up either.

4

Hey guys,

I had someone else ask about this so I put together an example of checking group membership with windows authentication and claims-based authorization.

https://docs.universaldashboard.io/security/authentication/windows#claims-based-authorization-with-windows-authentication


$AccountingPolicy = New-UDAuthorizationPolicy -Name "Accounting" -Endpoint {
    param($ClaimsPrincipal)
    $ClaimsPrincipal.HasClaim("http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", "S-1-5-21-931991156-4110752182-3137855529-1012") 
}

$AdminPolicy = New-UDAuthorizationPolicy -Name "Admins" -Endpoint {
    param($ClaimsPrincipal)
    $ClaimsPrincipal.HasClaim("http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", "S-1-5-21-931991156-4110752182-3137855529-1011")
}

$AuthMethod = New-UDAuthenticationMethod -Windows
$LoginPage = New-UDLoginPage -AuthenticationMethod $AuthMethod -PassThru -AuthorizationPolicy @($AccountingPolicy, $AdminPolicy)

$AdminPage = New-UDPage -Name "Admins" -AuthorizationPolicy "Admins" -Content {
    New-UDCard -Title "Admins" -Content {}
}

$AccountingPage = New-UDPage -Name "Accounting" -AuthorizationPolicy "Accounting" -Content {
    New-UDCard -Title "Accounting" -Content {}
}

$Dashboard = New-UDDashboard -LoginPage $LoginPage -Title "Hi" -Pages @($AdminPage, $AccountingPage)

Start-UDDashboard -Wait -Dashboard $Dashboard -AllowHttpForLogin
2 Likes
5

Oh and for the design terminal: use the -Design flag of the Start-UDDashboard cmdlet.

You can then inspect the $ClaimsPrinciple

image
image.png1609×324 50.2 KB

1 Like
6

Thank you!

I may be missing something simple, but there seems to be some sort of syntax issue using the full URI for the Claim type. When I have:

$ClaimsPrinciple.HasClaim(“http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, “S-1-5…”) I get a 500 Internal Server Error when trying to access any page (even ones without Policies).

  1. Request URL:

http://siteremoved:10000/api/internal/dashboard

  1. Request Method:

GET

  1. Status Code:

500 Internal Server Error

If I change to:

$ClaimsPrinciple.HasClaim(“groups”, “S-1-5…”)

Pages load fine, but the policy doesn’t work as “groups” is not the correct type so it doesn’t evaluate to TRUE

The Design option is great as I can see that I have the correct claim, I am just not sure why the full http://… type is causing an internal server error.

7

Can you please post the full code for your authorization policy?

8

I am redacting the last part of the SID as per policy

$AdminPolicy = New-UDAuthorizationPolicy -Name “Administrator” -Endpoint {
param($ClaimsPrinciple)
$ClaimsPrinciple.HasClaim(“http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, “S-1-5-21-XXXXXXX”)
}

$Auth = New-UDAuthenticationMethod -Windows

$LoginPage = New-UDLoginPage -AuthenticationMethod @($Auth) -PassThru -AuthorizationPolicy @($AdminPolicy)

Please let me know if any other sections would be useful

9

Hmmm very strange. Can you try enabling logging and uploading the log?

Enable-UDLogging -FilePath myFilePath.txt

10

It creates a log file, but I also get a Logging library error in the Browser. I will email you the log file. The Logging.Abstractions DLL is present in the netstandard2.0 as well as the net472 folder, so I am not sure why it wouldnt load. This is running in IIS if that matters.

An error occurred while starting the application.

FileLoadException: Could not load file or assembly ‘Microsoft.Extensions.Logging.Abstractions, Version=2.0.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

UniversalDashboard.ServerStartup.Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory, IApplicationLifetime lifetime)

  • FileLoadException: Could not load file or assembly ‘Microsoft.Extensions.Logging.Abstractions, Version=2.0.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

    • UniversalDashboard.ServerStartup.Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory, IApplicationLifetime lifetime)

    • Microsoft.AspNetCore.Hosting.ConventionBasedStartup.Configure(IApplicationBuilder app)

    • Microsoft.AspNetCore.Hosting.Internal.WebHost.BuildApplication()

11

The code and information worked great Adam, thank you.

I tried the UDLogging too on my system and got the same errors andon07 did.

12

I believe that I have found the issue, although I cannot explain it.

It seems the colon : in http:// is causing the Internal Server Error as when I remove it there is no error

($ClaimsPrinciple.HasClaim(“http//schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, “S-1-5-21-XXXXXXX”)) = No Error

Strangely enough, if I escape the : I also get the error

($ClaimsPrinciple.HasClaim(“http`://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, “S-1-5-21-XXXXXXX”)) = 500 Error

This seems it is an issue only for me as dcherry88 says the code works fine. Also if I run the correct string with the : inside the Design window, it evaluates to True

I am going to play around and see if I can identify why this is happening, so far I have tried single quotes, double quotes, setting a [string] variable and using that variable in the HasClaim() as well as setting to a System.Uri and pulling out AbsoluteUri property which I know is a string as well, so it doesn’t seem to be a type issue. All have the same Internal Server Error unless the : is missing or escaped.

Any thoughts would be greatly appreciated.

13

I will raise an issue for the logging.

14

Can you try using the Design Terminal to run that command in the browser? I want to see if we can see an exception coming back.

The logging didn’t contain the exception.

15

The

$ClaimsPrinciple.HasClaim()

command? I cannot include the exact command as I am getting a site violation for the URL, but the exact command that causes an error when in my dashboard.ps1 file returns [true] in Designer.

It is very strange, almost like IIS or PS or .NET is trying to render the string inside HasClaim() as a URL and throwing a 500 Error due to the :

I see many discussion around IIS and : in URLs causing 500 errors, which may be coincidental as this shouldn’t be treated as a URL within the HasClaim() method, but seemed interesting that there was that connection.

I am looking through some ProcMon outputs as well as DebugDiag reports to see if I can find anything suspsicious, but so far I cannot find the reason. Thanks!

16

I have tracked it down to some sort of permission/right issue when a policy is enforced on a page, although I do not know what specifically.

The issue occurs only when there is a policy attached to a page with -AuthorizationPolicy (any page, not even one that a user is trying to access when the error occurs). If I have the New-UDAuthorizationPolicy specified with a valid HasClaim() type string but no page has a policy applied, all accounts work. As soon as I apply a policy to any page with “-AuthorizationPolicy”, Account A (normal account) does not work (Internal Server Error), but Account B does work (elevated Admin account).

With a non-valid HasClaim() type string both accounts work even with a policy is assigned to pages. So it seems that when the New-UDAuthorizationPolicy doesn’t evaluate correctly, it doesn’t matter that a page is protected by a policy and Internal Error occurs.

I have also ruled out a source PC based issue as if I am logged into PC as Account A, and set a credential for Account B with cmdkey, it works as Account B, so I know it doesn’t matter which PC I connect from, it works and doesn’t work based solely on the credential being presented to IIS.

Is there anything happening behind the scenes with the the Policy enforcement on pages that may result in a permission based error if an account is lacking a permission or right of some kind? Unfortunately all I can see is “Internal Server Error 500” so I cannot tease out what permission or right is missing. I have made account A a local administrator on the server, but that does not resolve the issue. Account B is not a domain admin, but does have fairly wide permissions granted, so I am not sure what it has that is allowing it to work when Account A does not.