Users unable to view the main Dashboard

[aflatto]

Users are unable to see the dashboard

Expected Behavior

When a user logs in to the icingaweb interface he should be able to see the main dashboard and the current incidents

Current Behavior

Any users defined (beside the administartor group) , can not see any of the dashboards or the full menu on the side bar.

Context

The users are unable to view the dashboard and also can not work with the director to update the configuration

Your Environment

• Icinga Web 2 version and modules (System - About): 2.4.2
• Version used (icinga2 --version): 2.6.3
• Operating System and version: CentOs 6.9
• Enabled features (icinga2 feature list): api checker command ido-mysql mainlog notification
• Config validation (icinga2 daemon -C):

information/cli: Icinga application loader (version: v2.6.3) information/cli: Loading configuration file(s). information/ConfigItem: Committing config item(s). information/ApiListener: My API identity: l-ic-m-01.mtl.labs.mlnx warning/ApplyRule: Apply rule 'elk-report-build' (in /etc/icinga2/static/recurring-downtimes/downtimes.conf: 2:1-2:53) for type 'ScheduledDowntime' does not match anywhere! warning/ApplyRule: Apply rule 'daily-db-mars-query' (in /etc/icinga2/static/recurring-downtimes/downtimes.conf: 11:1-11:56) for type 'ScheduledDowntime' does not match anywhere! information/ConfigItem: Instantiated 1 ApiUser. information/ConfigItem: Instantiated 1 ApiListener. information/ConfigItem: Instantiated 8 Zones. information/ConfigItem: Instantiated 1 FileLogger. information/ConfigItem: Instantiated 12 Endpoints. information/ConfigItem: Instantiated 5422 Notifications. information/ConfigItem: Instantiated 6 NotificationCommands. information/ConfigItem: Instantiated 214 CheckCommands. information/ConfigItem: Instantiated 118 HostGroups. information/ConfigItem: Instantiated 1 IcingaApplication. information/ConfigItem: Instantiated 2 EventCommands. information/ConfigItem: Instantiated 2009 Hosts. information/ConfigItem: Instantiated 2927 Users. information/ConfigItem: Instantiated 41 UserGroups. information/ConfigItem: Instantiated 4751 Dependencies. information/ConfigItem: Instantiated 1 TimePeriod. information/ConfigItem: Instantiated 3 ServiceGroups. information/ConfigItem: Instantiated 7564 Services. information/ConfigItem: Instantiated 1 ExternalCommandListener. information/ConfigItem: Instantiated 1 CheckerComponent. information/ConfigItem: Instantiated 1 IdoMysqlConnection. information/ConfigItem: Instantiated 1 NotificationComponent. information/ScriptGlobal: Dumping variables to file '/var/cache/icinga2/icinga2.vars' information/cli: Finished validating the configuration file(s).

[Thomas-Gelf]

@aflatto: guess they'll not be able to help you unless you provide the details I asked you for. But who knows, eventually one of our web developers manages it to buy a cloudified crystal ball on Cyber Monday ;-)

[aflatto]

these are the roles in the configuration:

[Administrators] users = "anton,assaff" permissions = "*"

[Base_user] permissions = "*" users = "*,!assaff,!anton"

content of the groups.ini:

[icingaweb2] resource = "icingaweb_ldap" user_backend = "icingaweb2" group_class = "group" group_filter = "" group_name_attribute = "gid" group_member_attribute = "member" base_dn = "" backend = "ldap"

Anything else ?

[Thomas-Gelf]

The user you're authenticated with is not in this file. And even if it was, with permissions = "" it wouldn't have any permission. Last but not least there is no such thing such as users = "!username". This roles.ini perfectly reflects what your second screen-shot is showing: there are not permissions granted. It should in no way be related to your first screen-shot.

[aflatto]

@Thomas-Gelf the roles.ini contains this : [Administrators] users = "assaff,anton" permissions = "*"

[Base_user] users = "*" permissions = "application/stacktraces, application/log, admin, config/*, module/director, director/api, director/audit, director/showconfig, director/deploy, director/hosts, director/servicesets, director/service_set/apply, director/users, director/notifications, director/*, module/doc, module/monitoring, monitoring/command/*, monitoring/command/schedule-check, monitoring/command/acknowledge-problem, monitoring/command/remove-acknowledgement, monitoring/command/comment/*, monitoring/command/comment/add, monitoring/command/comment/delete, monitoring/command/downtime/*, monitoring/command/downtime/schedule, monitoring/command/downtime/delete"

yet the users still can not see anything while I in the admin group can see everything ?

[Thomas-Gelf]

@aflatto: now THIS helps, thank you! I guess it works for you if you place a list of single user- or group-names instead of a wildcard into your Base_user role? The wildcard should have worked until v2.2 or similar and unfortunately got broken at some point in the past. This should be fixed with the v2.5.0 version we're going to release today. @lippserd: please correct me in case I'm wrong on that.

[aflatto]

@Thomas-Gelf adding individial users to the role is a bit of an issue as we have +2k users to add (hence the user of the wildcard) , but if the issue will be resolved today then we can wait for that.

[Thomas-Gelf]

@aflatto: that's what groups have been invented for ;-) I've been told that way it works fine with 600k users in an Active Directory tree :p Navigating them makes no fun, but permission assignment should work flawlessly.

If you want to be sure that we fixed your specific issue it would be great if you could (immediately) give the current master a try and let us know BEFORE we tag the new release ;-)

Thanks, Thomas

NB: If you give your 2k users the permissions in the above list you could also make all of them to admins. They would be allowed to raise their permissions on their own.

[aflatto]

@Thomas-Gelf , groups where considered, but due to the lak of order or structure in the AD of the customer, the overhead of trying to arrange some order in the grouping was deemed too time consuming.

[lippserd]

users=* and groups=* is supported in Web 2 >= 2.5.0: #3095.