(Permission?) Probs with filtering the report systems

Hello community!
I am about to get familiar with Icinga2 and we have a problem with reporting which I hope to get help/explanation here.

We have IcingaWeb2 v2.9.5 set up. Reporting v0.10, including pdf export and scheduling, is properly working on our RHEL8 system. Many different systems are being monitored and we have different subsets of people with different permissions.

There are host/service groups which names are staring with CDDR. They group all hosts/services which can be viewed from anybody who is allowed to login to our IcingaWeb frontend. This is realized by roles.ini as following:

users = “icingaadmin”
permissions = “"
monitoring/filter/objects = "

groups = “*”
users = “*”
permissions = “module/monitoring,user/password-change”
monitoring/filter/objects = “hostgroup_name=CDDR*&servicegroup_name=CDDR*”

If anybody - even icingaadmin - creates a report, any filter in that report is just applied to objects in those CDDR groups. No chance to include hosts and services which do not belong to that groups (unfortunately that are the most objects).
It seems to us like the reporting module accesses the database with some id that applies to that “*/*” section in roles.ini. Our expected behavior was that the reporting module acts with the same permissions as the user who is logged in trying to create a report.

I hope I could express the problem somehow clear enough with my (yet) limited skill about Icinga.
Do we have a wrong understanding about how reporting acts? Where could we start to troubleshoot? Is this expected behavior and we need to redesign our permissions?
1000Thx in advance for reading and your ideas on that!

is it icinga2 2.9 or icingaweb2 2.9?
whats the version of the other modules?

it also seams that the icinga admin is missing the following line:

unrestricted = “1”

without that the permission of [xxxxxxxxx] is applied which hides all other hosts.

Do you use the webinterface to setup these roles?
You need to logout and login to see these changes.

Sorry for being unclear on that version. I corrected my thread above accordingly. The following screenshots may provide comprehensive version information.


Thx for your hint! I will check on that. It may takes a moment as I just have a production environment available for that and need to act rather carefull :wink:

Addendum: We have set up the roles by editing roles.ini directly.

you can set up roles in:


and let me guess, you are running icinga2/icingaweb2 on an EL8 linux?

Yes, you are right. We are running Icinga2 on a RHEL8.

And again yes, you are right. We did not pay attention to the refusals and adding unrestricted=“1” to icingaadmin got it going :slight_smile:
At least icingaadmin can now create reports of all objects :slight_smile: I need to re-think about our permissions and restrictions.

We are running 2 instances of Icinga2 which are provided with URLs from a Netscaler. Both Icinga instances share a clustered MariaDB (Galera). I guess this is the reason why we are editing directly roles.ini and role out any change to the second Icinga instance. Using the WebFrontEnd, we would apply any change to just one instance.
I need to discuss/question this with my colleague, since I did not attend during installation/design time.

Again 1000thx for your hint! I have now an clear idea about who to proceed!

Hello @moreamazingnick , hello all!

I need to follow up on this issue as I still have a problem here :frowning:

Setting a role (the Administrators role) to “unrestricted” resolved the problem for this role. But surely we have more roles which are not supposed to be unrestricted.
I have done some investigations on a test system and came across the following:

This thread states that the same filter rules as for Icingaweb2 would apply to the Icinga reporting module.
One part of the filter rules is the OR relation when a user belongs to 2 different roles:

Now I have the following roles.ini:

--------- snip --------------------------------------->
groups = “Group1”
permissions = “application/announcements,application/log,user/password-change,module/idoreports,module/monitoring,monitoring/command/schedule-check,monitoring/command/acknowledge-problem,monitoring/command/remove-acknowledgement,monitoring/command/comment/,monitoring/command/downtime/,monitoring/command/feature/object/*,monitoring/command/send-custom-notification,module/reporting,monitoring/view/Unix”
monitoring/filter/objects = “*”

groups = “*”
users = “*”
permissions = “module/monitoring,user/password-change”
monitoring/filter/objects = “host_name=tlin*”
<------- snap ----------------------------------------

I tested this and checked the amount of host which are visible to a user who belongs to Group1.

  1. in Icingaweb2 via “Overview - Hosts
  2. in Reporting via a report which has no filters and applies to all hosts visible to the user

As a result the user comes to see all Hosts in the Overview while he gets only a report among the Hosts which names are starting as “tlin”.
It seems to me like the Reporting module does not consider the filter monitoring/filter/objects = “*” but just and only monitoring/filter/objects = "host_name=tlin"*. Or lets say somehow like AND related.

What do I miss here? Any further idea for me?
1000Thx in advance!

that looks like an invalid rule:
try something like host_name=*|service_name=*

Thx for the hint!

I changed the roles as following:
--------- snip --------------------------------------->
groups = “Group1”
permissions = “application/announcements,application/log,user/password-change,module/idoreports,module/monitoring,monitoring/command/schedule-check,monitoring/command/acknowledge-problem,monitoring/command/remove-acknowledgement,monitoring/command/comment/,monitoring/command/downtime/,monitoring/command/feature/object/*,monitoring/command/send-custom-notification,module/reporting,monitoring/view/Unix”
monitoring/filter/objects = “host_name=*”

groups = “*”
users = “*”
permissions = “module/monitoring,user/password-change”
monitoring/filter/objects = “host_name=tlin*”
<------- snap ----------------------------------------

But it did not change things :frowning: While the user still sees all hosts in the Overview, he just sees the “tlin”-hosts when creating a report. So it still looks like the Reporting Module does not combine the 2 filters.

It seems like this behavior seems somehow remarkable to you as well. Therefor I conclude that at least my thoughts are so far correct: it would be to expect that in the above configured roles, a member of Group1 is supposed to see all hosts in the Overview as well as in Reporting.

Thx again for your help!

do you have a filter rule in the report?

I have no filter in the Report defined:

But I tried as well a Report filter as host_name=“*” at this point.

why do the users have the “tin” restriction anyway, if the report should contain more hosts?
also consider the following steps:

  • a repository subscription
    • your icingaweb2 is outdated
    • your monitoring module is outdated
      • you can also update this manually, but for newer EL8 packages you need a subscription
    • your idoreports module is outdated

last but not least: the ido as well as the monitoring module are deprecated.

I have no idea if any of these updates will solve your problem.

But you can set up a ubuntu machine with the newest free available packages and report if this problem still persists.

also try to remove ipl and reactbundle as it is now in the packages (icinga-php-library, icinga.php-thirdparty)
there are some old modules that require the old libs as modules (ipl and reactbundle), but from your screenshot i cant see one

We intent to apply the role [xxxxxxxxxxxxx] on users which are not explicitly covered by another role. Those users do not have the permission to generate a report but they should see a certain subset of hosts in Icingaweb2 Overview. Other users which are covered by other roles should be able to see all hosts in the Overview and the Reporting.
I started this thread for another approach to this requirement.

I want to understand how things are working here, since I am about to get myself familiar with Icinga2. It seems to me that I at least understand it somehow and there is some issue with passing the roles to the Reporting Module.

Yes, you are right! I already came across our outdated Software stack and it is on the ToDo-List. But in our environment it is always time consuming to finally update a Software. And it certainly needs to be RHEL8.

I guess I rather continue to update our Icinga2 installation, before continuing with that Security topic.

Thx again for your assistance here!

And … I wasn’t aware of those subscriptions. I will check on that!