# Icinga 2 API LDAP / Active Directory Authentication Roadmap **URL:** \ **Category:** Icinga 2\ **Created:** [October 2, 2026, 8:58am UTC](https://community.icinga.com/t/icinga-2-api-ldap-active-directory-authentication-roadmap/15601 "2026-10-02T08:58:16Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![FiratAlkis](https://community.icinga.com/letter_avatar_proxy/v4/letter/f/c6cbf5/32.png) [@FiratAlkis](https://community.icinga.com/u/FiratAlkis)\ **Post date:** [October 2, 2026, 8:58am UTC](https://community.icinga.com/t/icinga-2-api-ldap-active-directory-authentication-roadmap/15601/1 "2026-10-02T08:58:16Z")
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. ---
**Author:** ![moreamazingnick](https://community.icinga.com/user_avatar/community.icinga.com/moreamazingnick/32/7725_2.png) [@moreamazingnick](https://community.icinga.com/u/moreamazingnick)\ **Post date:** [October 2, 2026, 9:26am UTC](https://community.icinga.com/t/icinga-2-api-ldap-active-directory-authentication-roadmap/15601/2 "2026-10-02T09:26:38Z")
looks dead to me: > > > At the moment one has to store all API users with their cleartext passwords in t…he Icinga 2 config. > > \[Not all of the users like this\](https://github.com/Icinga/icinga2/issues/6905#issuecomment-456860196) as some would like to manage the users of their whole infrastructure centrally. > > My suggestion: \*\*Generic authn/z backends\*\* like already possible e.g. in Icinga Web 2, configurable like any other Icinga 2 object: > > \`\`\` > object AuthnCommand "msad" { > command = \[PluginDir + "/authn\_msad.py", "$url$" \] > } > > object AuthnBackend "msad-192.0.2.1" { > command = "msad" > vars.url = "ldap://192.0.2.1" > } > \`\`\` > > Icinga 2 would unconditionally invoke \`/usr/lib/nagios/plugins/authn\_msad.py ldap://192.0.2.1\` and communicate with that process via std I/O. > > If a user with the credentials \`root:123456\` can't be authenticated as usual, Icinga 2 sends \`"root:123456\\n"\` and expects either \`/(0|\[1-9\]\[0-9\]\*)\\n/\` with $1 being the amount of seconds \`root:123456\` doesn't have to be re-validated for or \`"-1\\n"\` in case of an invalid username or password (or an error). 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) > **[Using the Icinga Web API](https://icinga.com/blog/using-the-icinga-web-api/)** > > Unfortunately, there is little to no documentation for using the Icinga Web API to perform monitoring actions such as scheduling downtimes. But it's a These forms are api capable so downtimes set using some curl magic. for hosts and services this explaination might help > [@State history is not updated when plugin output changes without a state change Show more lines](https://community.icinga.com/t/state-history-is-not-updated-when-plugin-output-changes-without-a-state-change-show-more-lines/15569/4): > > If it helps you could use icingadb-web api to query hosts: username demo password demo https://demo.icinga.com/icingadb/services?service.name~File%2A&format=json create a filter or not, and copy link address of the export-\>json works for hosts services and so on. and it is machine readable json. just use basic auth on your script. you can also copy the query url directly and just set the header in your script to 'headers' =\> [ … 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. ---
**Author:** ![FiratAlkis](https://community.icinga.com/letter_avatar_proxy/v4/letter/f/c6cbf5/32.png) [@FiratAlkis](https://community.icinga.com/u/FiratAlkis)\ **Post date:** [October 15, 2026, 10:52am UTC](https://community.icinga.com/t/icinga-2-api-ldap-active-directory-authentication-roadmap/15601/3 "2026-10-15T10:52:44Z")
Thank you for the feedback. From a technical perspective, local ApiUser accounts and X.509 certificates are indeed valid authentication mechanisms and we acknowledge that certificate-based authentication is often considered more secure than username/password authentication. However, our request is not driven by a lack of existing authentication methods. It is driven by enterprise governance, audit and operational requirements. In large organizations, especially in banking and regulated environments, API consumers are frequently required to authenticate through centralized identity providers such as Active Directory or LDAP. This provides: - Centralized identity lifecycle management - Automatic account provisioning and deprovisioning - Password policy enforcement - Unified auditing and access reviews - Compliance with internal security standards Interestingly, Icinga Web already supports LDAP / Active Directory authentication, while the Icinga 2 API currently relies on local ApiUser objects or client certificates. [[icinga.com]](https://icinga.com/docs/icinga-web/latest/doc/05-Authentication/), [[github.com]](https://github.com/Icinga/icingaweb2/blob/master/doc/05-Authentication.md) During our evaluation we successfully integrated certain workflows through the Icinga Web endpoints because they can participate in our enterprise authentication model. However, for automation and system-to-system integrations, native LDAP-backed authentication on the Icinga 2 API would provide a more consistent enterprise experience. We are not suggesting that LDAP should replace existing authentication mechanisms. Rather, we believe it would be valuable as an additional authentication backend option, similar to the authentication flexibility already available in Icinga Web. [[community.icinga.com]](https://community.icinga.com/t/icinga-2-api-ldap-active-directory-authentication-roadmap/15601), [[icinga.com]](https://icinga.com/docs/icinga-web/latest/doc/05-Authentication/) Our intention is to help make Icinga easier to adopt in highly regulated enterprise environments, not because the current API is insufficient, but because centralized identity integration is often a prerequisite for wider platform adoption.