Ldap integration for thruk roles

[vercetty92360]

Is your feature request related to a problem? Please describe. I would like to add ldap groups in cgi roles (like "authorized_for_XXX") We manage all ou user permission based on their group. Right now, to authorize someone in a role, we need to add the user manualy in the cgi file. Would be good if we can set role per group, so to authorize a user, we just need to add him in an ldap group

Describe the solution you'd like being able to set ldap group in cgi.cfg for roles

Describe alternatives you've considered the alternative, right now, is to allow everyone as admin (lazy method), or to manually add a user on specific on ALL ou thruk instances

Additional context Hi,

I'm looking for a solution since it's several days. not sure if it's possible currently (if not, then it could be a great geature), and if it's possible, really sorry but I didn't find how to do that, any help would be appreiciated. Thx a lot!

[sni]

There is no such thing in Thruk. But you could write an exporter Script for LDAP which does this for you automatically.

[vercetty92360]

Hi

Yes I thought that too. and I guess this will never be integrated?

thx for your return

[sni]

I have no plans to do so. Also ldap setup is so uniq in every company, it would be a mess to implement a generic solution. But you are welcome to post your solution as example for others.

[llange]

There is no such thing in Thruk. But you could write an exporter Script for LDAP which does this for you automatically.

Hi @sni, also interested in this. Which kind of exporter script had you in mind ? A (cron-based or so) export of the usernames to the cgi.cfg, based on their remote (LDAP, ...) group mapping ? In that case, should we restart Thruk so that cgi.cfg is taken into account ? Or is it taken into account at the next request ?

(My use-case is similar. Not using LDAP directly but ADFS with mod_auth_mellon (SAML) integration.)

---

Another idea that I had in mind was to completely (and optionally) replace the concept of "contactgroup" (coming from the monitoring core) with an "external contactgroup" (coming from some ENV variable for example) - allowing the mapping to be defined from the authentication module (like external LDAP / .... ). Thruk would still do the authorization part with cgi.cfg etc... A little bit like using REMOTE_USER env variable when use_authentication = 1, but for contactgroups. (mod_auth_mellon has this export of groups in environment variables, and mod_authnz_ldap also does)

It sure looks like a more intrusive patch with more potential for bugs and regression.

What is your idea ? Should we explore this way also or is it going to be complex ?

[sni]

I have nothing specific in mind. But yeah, "simply" query the ldap and write the cgi.cfg. Changing the cgi.cfg does not require a restart of Thruk. Everything from the cgi.cfg has been merged into the thruk.conf, so you could also write into a thruk_local.d/generated.cfg. But then you had to reload Apache (But only if anything has changed).

Getting groups from env variable would require some changes and probably some mapping as well.

[klaernie]

We use one of the extractor setups:

• our authentication is based on SSL Client Certificates
• we regularly run a script that touches files named after the certificate common name (if the certificate is Subject: CN=klaernie,OU=something a file /etc/thruk/allowed-users/klaernie gets created), and files not touched in the last 7 days get removed
• in cgi.cfg we allow access to everybody (*)
• finally in our apache config we test for the existence of the file to determine access:

  <Location /thruk/>                                                                                                                                                                      
              AuthName "Thruk Monitoring"
              AuthType Basic
              AuthUserFile /etc/thruk/htpasswd
              <RequireAny>
                      Require valid-user
                      Require expr ( -f "/etc/thruk/allowed-users/%{SSL_CLIENT_S_DN_CN}" )
              </RequireAny>
  </Location>
  

I simplified for this example, but we also distinguish between people allowed to run commands and people not allowed to, that just works by using multiple allowed-users directories.

Recently I found one security hole in my scheme that needed patching: the entire /thruk/r path also allowed sending commands, so I restricted the allowed HTTP methods (AllowMethods GET HEAD OPTIONS)

One could apply the same principle by pulling allowed users out of LDAP and touching files to them, but it would also be possible to let apache run queries against LDAP directly. In our case the source are distribution lists accessible via an internal API, which is the best way for us.