Icinga 2 API LDAP / Active Directory Authentication Roadmap

Icinga 2
1

Hello Icinga Team,

We are currently evaluating the usage of the Icinga 2 API for enterprise integrations.

At the moment, the Icinga 2 API supports:

ApiUser with password
ApiUser with X.509 client certificates

However, LDAP / Active Directory authentication does not appear to be supported for the Icinga 2 API. According to previous community discussions, API authentication is currently based only on ApiUser objects and client certificates.

We would like to know:

Is LDAP / Active Directory authentication for the Icinga 2 API currently on the roadmap?
Has the Icinga team discussed adding support for enterprise identity providers (LDAP / AD)?
Are there any architectural reasons preventing such integration?
Would the Icinga team consider a feature request for LDAP-backed API authentication?
Enterprise Use Case

In many enterprise and banking environments, the use of local application accounts is often restricted by security policies, audit requirements, and regulatory controls.

Even when the monitoring platform itself does not contain highly sensitive information, integrated systems may have critical business impact classifications (BIA levels). Because of this, organizations often require:

Centralized identity management
AD/LDAP lifecycle management
Central password policies
Automatic account deprovisioning
Auditability of user access
Compliance with internal and external regulations

While client certificate authentication is a strong alternative and supported by Icinga 2, some organizations still require user-based authentication through centralized identity sources such as Active Directory.

We would appreciate any information regarding future plans, existing discussions, or recommended enterprise approaches.

Thank you.

2

looks dead to me:

but maybe we can figure something out to use icingaweb2/icingadb api.

  • Why do you need access to the icinga2 api directly?
    • Query Hosts / Services?
    • Set Downtimes?

All this can be done using curl requests against the icingaweb2 module (monitoring or icingadb)

These forms are api capable so downtimes set using some curl magic.

for hosts and services this explaination might help

And since icingaweb2 can do ldap you are good to go.

One alternative, you can always add a proxy that knows “icinga2 credentials” maps the ldap user to an api user.