Icinga2 Agent get's "Access denied" by running centreon_plugins.exe

Hello everyone,

I’m running into an issue with executing Centreon plugins via the Icinga2 agent on Windows, and after checking with the Centreon support team, it seems the problem is related to the Icinga2 configuration rather than the Centreon plugins themselves.

Problem description

I installed centreon_plugins.exe on three different Windows hosts.
Running standard Icinga2 agent checks works fine, but executing Centreon plugins via Icinga2 does not.

I tested two different plugins to avoid a plugin-specific issue:

  • apps::backup::veeam::local::plugin

  • os::windows::local::plugin

Both fail with the same error message:

Command "C:\Program Files\ICINGA2\/sbin/\"C:\Program" "Files\ICINGA2\sbin\centreonplugins\src\centreon.cmd\"" --plugin apps::backup::veeam::local::plugin --mode list-jobs failed to execute: 5, "Access is denied."<Terminated with exit code 127 (0x7F).>

Command "C:\Program Files\ICINGA2\/sbin/\"C:\Program" "Files\ICINGA2\sbin\centreonplugins\src\centreon.cmd\"" --plugin os::windows::local::plugin --mode time failed to execute: 5, "Access is denied."<Terminated with exit code 127 (0x7F).>

Running the same commands manually works fine when executed as Domain Admin.

I already tested different user accounts for the Icinga2 Agent service:

  • Local System

  • Network Service

  • Domain Admin

The result is always the same: “Access is denied.”

The Icinga2 debug logs only show exit code 3 and the same access denied message. No further details.

Important note from Centreon support

I already opened a case at Centreon. According to their feedback:

The centreon_plugins.exe binary works fine.
You need to check the configuration of the Icinga2 agent, which we do not know and do not support here at Centreon.

So it looks like the issue is not caused by the plugins themselves.

Question

Is there any known issue, permission requirement, or special configuration for allowing Icinga2 on Windows to execute external commands like the Centreon plugin executable?
Are there recommended debugging steps on the Icinga2 side?

Information about the running icinga2:

Thanks in advance!

Hi @Krungs ,
This does sound very much like a permission problem. Likely the user running Icinga 2 does not have the necessary permissions (in contrary to the user your are using for testing).
You could change the Service user to the local administrator account, which is not recommended but might solve your problem.

Hi @lorenz,
as you surely read, I already ran the service as a Domain Admin. I have now also created a local admin and started the service with that account. The error still persists, only the exit code has changed (see screenshot).

image

I also don’t really understand how this could be related to permissions. Sure, the error says so, but even the Local System account operates at the highest level.

I just know noticed, that the executed path is quite weird, it seems like there is some duplication there.

C:\Program Files\ICINGA2\/sbin/\"C:\Program" "Files\ICINGA2\sbin\centreonplugins\src\centreon.cmd

looks rather irregular, you might want to change the Command in your CheckCommand definition to centreonplugins\src\centreon.cmd

You are right! It was an old test cause the docs said, that I can paste the full path to avoid issuse with german and english systems. I changed it an now get an another error. :smiley:

It now says that my command does not exist.

image

But I see it:

I guess that’s an another issue with the agent? Normal icinga2 checks are working fine, so it cant be port blocking or something else. In the wizard I also said to accept commands from the master.

Hm, if you scroll down on that page, there should a field “Check Source”, this would be the machine executing the check. Which machine is that?

That’s the machine with the agent. That’s because I set the option “Run on Agent” to “yes”. (Well i guess that should be the reason.)

ok, I guess then, that the CheckCommand object is not synced to the agent.

Take a look a the Centreon_Veeam CheckCommand in the director, what is the Zone there? This Zone must be available on the primary instance (“master”) AND on the agent.

I have 3 zones:

These zones are global. SYSMON1 is the zone from my “master”, thats the icinga2 host. every host, service an command is assigned to this zone.

Host:

Service template:

Command:

I also checked the zones.conf on the agent an it is there:

I see the zone “master” but if i want to rename it or change the parent, the agent wont start.

Why? This looks wrong to me!

This is what gets created during the configuration.
How should it look if you think it’s wrong?

/*
 * Generated by Icinga 2 node setup commands
 * on 2024-11-12 19:00:10 +0100
 */

object Endpoint "icinga1" {
        host = "icinga1"
        port = "5665"
}

object Endpoint "icinga2" {
        host = "icinga2"
        port = "5665"
}

object Zone "master" {
        endpoints = [ "icinga1", "icinga2" ]
}

object Endpoint "robore1" {
}

object Zone "robore1" {
        endpoints = [ "robore1" ]
        parent = "master"
}

object Zone "global-templates" {
        global = true
}

object Zone "director-global" {
        global = true
}

So I don’t have an extra zone duplicate zone for the master (SYSMON01 or icinga1).

On what zone on the master are u tagging the commands and so on? So i would rebuild it and see what happens.

global-templates for manual configs and director-global for director templates and commands.
The director manages director-global automatically as I don’t need to do much in this regard.

No explicit Cluster Zone results in zone director-global.


So in that case, when i change my zone in the command to “nothing”, it should work?

I will try it as soon as i am back on pc.

1 Like

Ok, i got some news.

By changing the zone, I got an another error. I fixed that, was just a type issue from “app” to “apps” in the Plugin.

Now I am back to the roots with:

UNKNOWN: Internal error: execution issue: Access is denied

I still had the local Admin to run the service but also changing it t “local system” doesnt make any difference.

Does it work, when started manually as normal local admin (not domain admin)?

What is the scheduling and check source?

Running the check as local admin on admin cmd works fine:

The source ist the agent:

These are the service settings:

Sorry for having my icinga in german, there are some colleagues at my work that cant really read english :smiley:

Macht nichts, ich bin Schweizer :wink:

So then it’s a question on which user is the Icinga2 service is running as on your Windows and what security restrictions are present. What shows up in the icinga2 log? Did you try with a temporarily deactivated Antivirus? Anything in the Eventlog? Can you access a Windows engineer at your workplace to help you with this?

The agent got testet as literally anything: dom admin, local admin, local system and network services. As long as I know, there are no restrictions for them, 100% sure for local system and network services.

The icinga debug log is not really helpfull as it says this:

image

(sorry that screenshot is micro af, but ist only says “exit code 3”)

The eventlogs doesnt show anything.

I can request to lower the AV but I have to do some consultations before I can do this.

I try to get anyone tomorrow so I can test it.

In that case I am the engineer, I have access to anything and everything. There are just some restrictions from above on how and when I can do some stuff about it.

I’ll text tomorrow about the AV.