Restricting login to admin interface while allowing authentication to dashboard

Is there a way to allow authentication to a dashboard while restricting login to the admin interface? I have a dashboard and I use the Authentication script to authenticate users in AD to allow access. I have also used the Roles script to assign roles that removes admin access to all users except those of a set AD group. However if an AD user, who is not in this admin group, authenticates they can still log into the Admin interface, even though they can’t do anything they can still click on things and launch the New Dashboard and other setup links. Nothing is saved or changed , but our security team will not allow the dashboard to go to production until we restrict access to the admin interface.

1 Like

This will be part of 1.5. It’s currently not possible to totally restrict the admin console based on role.

looking forward for the update. i am in the same situation :frowning:

I presume this has been added now, but i cant seem to find any documentation on how to implement… any ideas?

Hi, neo. I ran into something similar when I started. This is what I did (I am hosting through the Windows Service):

  • In appsettings.json, under Authentication>>Windows>>Enabled, set it to True.
  • Restart the service

This causes the following issue:
All authentication now goes through A.D., however by default all authenticated users (including NTAuthority\AnonymousUser) can log in with Admin rights.

To resolve this, you need to configure the roles. In the Admin console, browse to Settings>>Security. On the roles tab, edit the Administrator role to point to an A.D. security group. The documentation gives an example here: Security - PowerShell Universal. Once I was confident in testing the authentication, I just removed the lines where it is writing out to the text file.

I then disabled the other roles (reader, operators, etc.), until I had a use for them, by setting them like so:

param(
    $User
)

$UserName = ($User.Identity.Name)
$UserName = $UserName.Split('\')[1]

$IsMember = $false;
$IsMember

Now users must authenticate when hitting the admin console, and only those in my security group are allowed access. Hope this helps.

Hey @JLogan3o13 thanks for that idea. That will work if you’re not using authentication on dashboards also though hey?

I have a situation where there is 1 dashboard running and I want to restrict access to that via an AD group (using Windows Auth). This works by setting a psurole in Roles.ps1 named like “Reader” and setting the value to $true when the user is a member of a certain ad group (ACL-Dashboard-R).

Members of ACL-Dashboard-R:
[me]
[PersonX]

In the admin console, the dashboard auth is set to only allow access to people in the “Reader” role.

So when I browse to the dashboard, it loads because I’m a member of the AD group ACL-Dashboard-R (which in turn means I’m part of the PSU role “Reader”, and that role has access to the dashboard).

When [PersonX] browses to the dashboard it loads because they are a member of the AD group ACL-Dashboard-R (which in turn means they are part of the PSU role “Reader”, and that role has access to the dashboard).

In Roles.ps1 there is also the “Administrator” psurole which only returns true when the user is [me].

So when I browse to the admin console it loads (because I’m a member of at least 1 role? not sure here?) - and I see the ‘Settings’ section because I’m part of the PSU role “Administrator”

edit: ^^^ the admin console loads for anyone who is a member of any of the default psuroles:

  • Administrator
  • Operator
  • Executor
  • Reader
    (to restrict access to the admin console, ensure the user is not being added to any of the default roles, and assign a new custom psurole, and don’t forget to add that custom role to the authentication on the dashboard that they need to be able to load)

And when [PersonX] browses to the admin console it loads but they don’t see the ‘Settings’ section because they are not part of the PSU role “Administrator”.

I don’t want [PersonX] to be able to load the admin console at all, which I can do by making sure they are not part of any PSU roles via Roles.ps1 - BUT I need them to be part of the “Reader” PSU role so that they have the ability to load the dashboard.

Any idea how to set that access up?

Cheers!
Steve.

In this case, you’ll want to use a custom role. If the user is part of any of the default roles (Administrator, Operator, Executor, Reader), they will have access to the admin console. If instead, they are only part of a role, say DashboardUsers, they will not have access to the admin console.

1 Like

Thank you!

I did not realise these were all default roles:

  • Administrator
  • Operator
  • Executor
  • Reader
    (I only thought ‘Administrator’ was)

Just tested that with a custom psurole named “DashboardAccess” and everything works a treat! Argh all I had to do was use a custom named role, haha! Thanks again for the help!

1 Like