Authorization Policies With IIS Don't Work As Expected

1

I’m running a dashboard in IIS with Windows Authentication and am having trouble getting authorization policies to work as expected, or my expectations don’t match reality. Consider this dashboard:

$Auth = New-UDAuthenticationMethod -Windows

$Policy1 = New-UDAuthorizationPolicy -Name "Policy1" -Endpoint {
    param
    (
        $ClaimsPrincipal
    )

    $ClaimsPrincipal.HasClaim("http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", "S-1-5-21-2640144-4251154575-XXXXXXXXXX-XXXX")
}

$Policy2 = New-UDAuthorizationPolicy -Name "Policy2" -Endpoint {
    param
    (
        $ClaimsPrincipal
    )

    $ClaimsPrincipal.HasClaim("http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", "S-1-5-21-2640144-4251154575-XXXXXXXXXX-XXXX")
}

$LoginPage = New-UDLoginPage -AuthenticationMethod $Auth -PassThru -AuthorizationPolicy $Policy1, $Policy2

$Pages = @(
	New-UDPage -Name "Nuffin" -Icon circle -AuthorizationPolicy @("Policy1","Policy2") -Content {
		New-UDCard -title Nuffin -Content {"Nuffin"}
	}
	
    New-UDPage -Name "Sumpin" -Icon circle -AuthorizationPolicy @("Policy1") -Content {
		New-UDCard -title Sumpin -Content {"Sumpin"}
	}
)

$Board = New-UDDashboard -Title "Test Authorization" -Pages $Pages -LoginPage $LoginPage

Start-UDDashboard -Dashboard $Board -Wait -AllowHttpForLogin -Design

I have two users - user1 has group membership to match Policy1, and user2 matches policy2. I would assume that this would allow access to the “nuffin” page for users that match either of the two policies, and the sumpin page would be limited to users that match only Policy1

When user1 logs in to the dashboard he is greeted by the “Sumpin” page, but there is no hamburger menu. I would expect to be able to view both pages as user1.

When user2 logs in he has no access at all and receives the error “You are not authorized to view any pages. Please contact your administrator.”

Is this how access control should work? If not, what am I doing wrong? How can I design authorization policies to selectively allow page viewing?

Thanks!

2

This should be fixed in the 2.4 release.

3

@Jacob-Evans thanks for the link! Are you sure that’s the same issue? If so, I may start testing with the 2.4 beta if the fix is included in that release.

EDIT: I think I understand now - when @adamdriscoll says that if the first policy “fails” he means that it evaluates to false, right? Then this makes sense. I’ll test by changing the order of the policies on the login page and see if the behavior changes.

4

Please test 2.4-beta for this. The policies were actually pretty jacked in 2.3.2. They seem to be much happier in 2.4.

1 Like
5

Yeah, that’s much better so far. The above script works as expected, and I’ve even gone a step further and provided a home page that’s open to anyone, and the two pages above still work with appropriate selective access. Thanks!

6

So I did get the basics of authorization working above, but as soon as I try to apply this to my production script it won’t launch in IIS. I keep getting a 502.5 error. As soon as I comment out the -LoginPage parameter the dashboard will launch. How can I get logs of what is going on in there?

7

Try turning on logging: Enable-UDLogging -FilePath [some path IIS can write to]

8

I can just add that right to the dashboard script?

9

yeah. Just throw it right in the beginning.

10

Bizarre! now I can’t reproduce the error, so the logging isn’t doing anything! :frowning:

I was consistently getting errors in the app log like:

Application ‘MACHINE/WEBROOT/APPHOST/DEFAULT WEB SITE’ with physical root ‘C:\inetpub\wwwroot’ failed to start process with commandline 'C:\inetpub\wwwroot\net472\universaldashboard.server.exe ', ErrorCode = '0x80004005 : ff.

and

Application: universaldashboard.server.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.Exception at UniversalDashboard.DashboardManager.Start() at UniversalDashboard.Program.Main(System.String[])

I made no significant changes and it’s now working! I’ve gotta track this down!

11

so I’m testing locally in IIS on windows 10 and can’t seem to repro the error again, even though it was happening earlier.

I added UDLogging on my test site that’s running on windows server 2016 IIS and I am not getting those logs but they don’t seem to have anything helpful in there since the process fails to launch. I don’t see any errors or anthing to indicate the problem.

12

Matt,

Is it possible you stepped into an alternate universe over lunch?

“Heisenbug” is my favorite IT slang term. And one of my least favorite to work with. :slight_smile:

Thanks,
Tim Curwick

13

It’s definitely possible! I was able to get logging out of UD on my test server finally, but all it stopped logging just before the dashboard launched. I’m guessing whatever is happening when the login page is enabled is crashing the whole process and the UDLogging with it.

I’m working to try to get access to the event logs on our test server to figure out what’s going on. At the moment though I can verify that as soon as I add the -LoginPage parameter to New-UDDashboard this begins to crash, and without it the dashboard runs.

14

Ok, i finally figured something out! When I was able to get .net logging going I was getting an error:

Login pages should not be used over HTTP. Specify a Certificate or CertificateFile to use a login page. To ignore this error, use AllowHttpForLogin. This should only be used for development purposes.

I added the switch to Start-UDDashboard on my test server and it began launching. I’m not yet sure what this indicates, but at least I’ve discovered what’s causing the crash. Does anyone have any thoughts on why this would be happening? I don’t have http bound for this site so I’m not sure what’s going on.

15

So… there’s a good chance I’m just a dummy! I added the -Certificate parameter to Start-UDDashboard and everything appears to be working correctly!

I suppose I had assumed from the start that configuring HTTPS on the dashhboard was not required if HTTPS is configured on the IIS website. I suppose that’s not the case, and I’m wondering if the end result then was something like a mixed-content scenario - e.g. serving up non-encrypted components on an encrypted site.