IIS Windows Auth not working for me

After setting up windows authentication, everyone has access to everything.

The $User variable is populated with my Domain/Username as is should so windows auth tokens is forwarded. but it is not respecting the Claims based policies I setup.

I setup 3 claims

$LeadershipTeam = New-UDAuthorizationPolicy -Name "LeadershipTeam" -Endpoint {
    $ClaimsPrincipal.HasClaim("http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", "S-1-5-21-1168975120-759244214-17591369-21363") 
$DepartmentManagers = New-UDAuthorizationPolicy -Name "DepartmentManagers" -Endpoint {
    $ClaimsPrincipal.HasClaim("http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", "S-1-5-21-1168975120-759244214-17591369-17202") 
$HRDepartment = New-UDAuthorizationPolicy -Name "HRDepartment" -Endpoint {
    $ClaimsPrincipal.HasClaim("http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", "S-1-5-21-1168975120-759244214-17591369-9938") 

I’m not a member of any of those groups.
Login page like this

$Auth = New-UDAuthenticationMethod -Windows
$LoginPage = New-UDLoginPage -AuthenticationMethod $Auth -PassThru -AuthorizationPolicy @($LeadershipTeam, $DepartmentManagers, $HRDepartment)​

and on the two test pages I have

-AuthorizedRole @("LeadershipTeam","HRDepartment")

Try turning on design mode. You can do this with the -Design switch on Start-UDDashboard. In there, try executing your policy checks to make sure you are getting back what you expect:

$ClaimsPrincipal.HasClaim("http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", "S-1-5-21-1168975120-759244214-17591369-9938")


UD > $ClaimsPrincipal.HasClaim(“http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, “S-1-5-21-1168975120-759244214-17591369-9935”)

{“error”:{“message”:“You cannot call a method on a null-valued expression.”,“location”:null,“type”:“error”,“id”:null,“refreshInterval”:0,“autoRefresh”:false,“hasCallback”:false}}

Try $ClaimsPrinciple (which is wrong, but that’s what it is.)


UD > $ClaimsPrinciple.HasClaim(“http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, “S-1-5-21-1168975120-759244214-17591369-9935”)


Ugh. https://github.com/ironmansoftware/universal-dashboard/issues/550

1 Like

I would have thought that the fallback action was “deny access” if there ever was an issue with the authorization.

I will have to see what’s going on there. I agree.

1 Like


Did authorization start working for you once you fixed matched the typo?


I can’t get it to work. The UDAuthorization endpoints don’t seem to be running at all. Does this bug break Windows-integrated authorization entirely? I can’t find where in your source code the login page is called to see if the right object is passed.

Tim Curwick

Nah, ran out of time, I’ll revisit it once it’s fixed.

Looking into this now. I am also seeing this no longer work. The source code for this is part of a private repo because it is part of the enterprise functionality.

I’ve created an issue here: https://github.com/ironmansoftware/universal-dashboard/issues/553

Ok. I have some more information.

I have fixed the issue where $ClaimsPrincipal is spelled wrong, where errors in a authorization policy will allow the user to continue and UD logging. I’m going to get nightly builds of the enterprise edition published somewhere as there isn’t a good way to expose an AppVeyor project for a private repo.

But, with the authorization policies themselves, they appear to be working. The problem I was having was that the group policy claims must be cached some how.

I have an Accounting and Admins group. I added my local user adamr to the accounting group. I can see both an Admin and Accounting page in this configuration. I then remove the user from the group and then open the dashboard again. I still have access to the Accounting page. I can see in the ClaimsPrincipal object that I still am receiving that group claim from IIS.

I was using Chrome. So I closed Chrome complete (no Chrome.exes running). I then launch it again, still same claim in there.

I then launch with Edge. It prompts me for a user name and password. I no longer have access to the accounting page and can see that claim is missing from my claims list.

I then log out completely of my Windows session (logged in as adamr) and then open Chrome again and go to the dashboard and no longer have access to the accounting page.

Can you please try the following steps and see if you have a similar experience?


I have been testing with a group that I am a member of and one that I have never been a member of. (I’m at a client and don’t have easy access to change membership.)

In design mode, I can see in my claims that I am a member of GroupA and not a member of GroupB.
I have a UDAuthorizationPolicy for each, and a test page for each.
Testing with Chrome, I have full access to both pages.
Logging out of and back into Windows or restarting my laptop have no effect.

If I try to test with Edge or Internet Explorer, I get a blank page instead of my home page or any other pages I try to go to directly, and am not prompted for credentials. (I presume that discussion will be a new thread.)

I added a command to one of my endpoints to write to a log. It never happens, implying the endpoint is never run.

Tim C

Here is the latest build with the fixes I mentioned: https://adamdriscollstorage.blob.core.windows.net/universaldashboard-releases/UniversalDashboard.

If you please try that in your environment and enable UD logging. The log path needs to be somewhere the AppPool user can write to.

Enable-UDLogging -Level Debug -FilePath C:\mylogs

This should give some more information on why the policy may not be invoked. Additionally, if you could post your dashboard script, that would be helpful.

As for the IE\Edge problem, can you open the F12 developer tools to see if you have any errors in there?

Where do I put Enable-UDLogging?

Put it in your dashboard.ps1 that you are deploying with your IIS site.

I finally got it working. I was using -AuthorizedRole with New-UDPage where I needed -AuthorizationPolicy.

There is at least one place in the code which still has the misspelling, as this line appears in the log:

16:23:32 [Debug] ExecutionService ClaimsPrinciple = System.Security.Claims.ClaimsPrincipal

And Get-UDElement appears to be broken in this build.

Tim Curwick

I left the missing spelling in there so I didn’t break people’s scripts. It should be setting both the incorrect and correct spelling now.

I’ll take a look at Get-UDElement.


I’m running into the same issues as above. I’m stumped I’m using my login as test here and have taken myself out of the groups in my claims for the time being. But I’m still able to load both dashboards. I know the login page is working because I get the Sign Out button when I load the webpage. So it has to be the claims not taking effect. Unfortunately when I attempt to Enable-UDLogging IIS won’t start. Is there a certain place that needs to be called in the dashboard.ps1? If it helps my current running version of UD is 2.2.1.

I’ve configured IIS for Windows Authentication per - https://github.com/adamdriscoll/universal-dashboard-documentation/blob/master/security/authentication/windows.md

My Claims are setup like so:

$SupportPolicy = New-UDAuthorizationPolicy -Name "Support" -Endpoint{
    $ClaimPrincipal.HasClaim("http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", "S-1-5-21-48200957-2212589444-2584372378-1151")

$AdminPolicy = NewUDAuthorizationPolicy -Name "Admin" -Endpoint{
    $ClaimPrincipal.HasClaim("http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", "S-1-5-21-48200957-2212589444-2584372378-20173")

Login Page:

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

Support Page:

New-UDPage -Name "Support-Tools" -AuthorizationPolicy @("Admin", "Support") -Icon user -Content{...

Admin (Dev) Page:

New-UDPage -Name "Dev-Board" -AuthorizationPolicy "Admin" -Icon user -Content{...

Any idea how to fix logging and or why the claims aren’t processing correctly?

Attempted to Update to Build @adam posted above and it broke IIS. Getting tons of application errors after the update. I redeployed from my backup and got everything working again. Is there a weird process for updating to this build? I thought I could just move the new files over to the webroot and restart the IIS Server.