Hello,
I’m searching for a way to enable/disable the maintenance mode for specific hosts using some sort of API.
Because I use the LDAP backend for authentication in IcingaWeb and all the host objects are mapped to groups, I want to use the same LDAP backend for user authentication on the API to limit the access for each user.
What is the recommended way to enable API access for ldap users to their objects?
Manuel
Hi,
the only way to authenticate against the API is either basic auth or client certificates, configured with an ApiUser object. You can restrict the ApiUser objects with specific permission filters, e.g. on host groups.
Possible custom solutions would be to write a script which generates Icinga 2 configuration based on the users found in specific LDAP groups, and set the permission filter accordingly for each user or group. Dump the configuration into Icinga, and reload. The main problem is that there’s no way back with the password, so you’d need to keep separate config/certificates.
Cheers,
Michael
Hi Michael,
thank’s for your answer. That’s what I did not hope for 
I did experiment with these filters a little bit and they seem to be very powerful.
This will probably the solution I go with; I just need to think about the user accounts themselfs. The environment is quite large, but only a handful of people really need access to the API. Maybe it’s best to just wrap some Puppet code around the creation of API users and define them that way. Then I should be able to also remove accounts which we don’t need anymore.
Cheers!
The question is, why your AD users need access to the REST API as well. Typically, you would use it from within Icinga Web 2 as command transport (single user), or in scripts scheduling downtimes/feeding check results, or likewise, some status dashboards. What’s the idea with providing access on the AD level?
Cheers,
Michael
All the systems are managed by their respective team when it comes to updates etc.
For that reason, they do updates either using a supported way (which we control and can modify on our side) or they use their own workflow (which is totally fine). For the second use case, it’s sometimes necessary to set a downtime or disable some checks for specific hosts (via script).
Because all objects are grouped by their respective owner (groups in AD) to control access within Icinga Web 2, it would be nice to use some sort of “technical account” which is a member of the same group and can do the same actions to the same group of objects.
So you’d need to generate ApiUsers for technical accounts only. Our managed service team does that via Puppet for instance, where the credentials are stored on the respective client customer boxes. Keep in mind though that either basic auth or client certificates work, there is no AD auth forwarding as you would know from mod_ldap and variants.
Cheers,
Michael