Is there a way to batch modify users?

[atc0005]

Hi,

We're running Nagios XI 5.8.7. Yesterday I received a report from someone that several of their team members received notifications for a failing service check, but were unable to acknowledge or disable notifications.

The reporter is a knowledgeable Nagios XI admin and suggested that all of our Nagios XI user accounts should have the 'Can configure hosts and services' "Security Settings" option enabled. He noted that this provides all contacts associated with a service check the ability to acknowledge or disable notifications for their team.

I checked and we have 148 user accounts.

I saw in this forum that there is an API available for Nagios XI:

https://YOURXISERVER/nagiosxi/help/api- ... p#add-user

I see that the API offers the ability to GET an existing user, POST a new user and DELETE an existing user. I don't see an option to update (PUT) an existing user account. Is this supported and perhaps just not documented in the API reference?

Aside from directly modifying each user account via the web UI, is there another option for batch enabling this setting for all user accounts?

Thanks in advance for your help.

[ssax]

You should be able to run this:

Code: Select all

mysql -uroot -pnagiosxi nagiosxi -e "UPDATE xi_usermeta SET keyvalue = 1 WHERE keyname = 'authorized_for_all_object_commands';"

Then go edit any user in Admin > Manage Users, validate it shows as changed, and click the Update User button on one of the users (it only needs to be done on a single user to update all users) so that it writes out the new /usr/local/nagios/etc/cgi.cfg file, then Apply Configuration.

[atc0005]

ssax,

Thanks for the reply.

Can you confirm that this query:

Code: Select all

UPDATE xi_usermeta 
SET keyvalue = 1 
WHERE keyname = 'authorized_for_all_object_commands';

only grants the ability to acknowledge or disable notifications for hosts/services that the user is a contact for and not all systems/hosts monitored by Nagios XI?

[ssax]

That gives these permissions globally on all hosts and services in the system if the user also has "Can see all hosts and services" permissions set:

Can control hosts and services:

The user can:

• Acknowledge problems
  Schedule downtime
  Toggle notifications
  Force checks on all objects

So if you want them to only be able to acknowledge the hosts/services they are a contact of it should work that way by default as long as they aren't a read-only user.

Please see here for more information:

https://assets.nagios.com/downloads/nag ... Rights.pdf

[atc0005]

ssax,

Thanks for your reply & help.

I think I understand, but will restate just to make sure I do:

If a user is not a read-only user and is a contact or a member of a contact group associated with a host/service then they should already be able to disable notifications for that host/service or acknowledge the notifications for that host/service. No changes are necessary to accomplish this.

If a user has previously been given the ability to see all hosts and services, the query you provided will now grant the ability to control all hosts and services. If we do not use the query you provided (and do not explicitly toggle the "Can see all hosts and services" permission), then these users will continue to see all hosts and services, but will be unable to control them unless they are a contact for the host/service or are in a contact group associated with the host/service.

Do I have that right?

Thanks again.

[ssax]

If a user is not a read-only user and is a contact or a member of a contact group associated with a host/service then they should already be able to disable notifications for that host/service or acknowledge the notifications for that host/service. No changes are necessary to accomplish this.

That is correct.

If a user has previously been given the ability to see all hosts and services, the query you provided will now grant the ability to control all hosts and services. If we do not use the query you provided (and do not explicitly toggle the "Can see all hosts and services" permission), then these users will continue to see all hosts and services, but will be unable to control them unless they are a contact for the host/service or are in a contact group associated with the host/service.

That is correct as well.

[atc0005]

ssax,

Thanks for your help thus far.

Prior to confirming the impact of the query, I ended up running it (about a week ago).

I've since rolled back the changes from the earlier UPDATE query by using this one:

Code: Select all

START TRANSACTION;

UPDATE xi_usermeta AS xi, (SELECT user_id FROM xi_usermeta WHERE keyname = 'userlevel' AND keyvalue = 1) AS u
SET keyvalue = 0 
WHERE 
    keyname = 'authorized_for_all_object_commands' 
    AND
    xi.user_id = u.user_id;

-- ROLLBACK;
-- COMMIT;

The intent was to remove the privilege for just the non-admin users. After confirming the intended results, I committed the transaction.

This puts us back at the point where I first opened the thread.

Our former Nagios XI administrator is a member of a team responsible for some new systems that are being rolled out. It is members of that team which were unable to disable notifications for a service check and acknowledge alerts for it and which I made reference to when I opened this thread.

The service check is defined as applying to a hostgroup and the members of that team are members of a Nagios XI contact group associated with the service check.

Using the masquerade option in the admin panel, the former Nagios XI admin attempted to disable notifications for a service check (applied by way of hostgroup membership) and was unable to do so.

Does this explanation supply any additional information which justifies the need for the "Can configure hosts and services" privilege for each user?

Please let me know if I can clarify.

Thanks.

[ssax]

Interesting, it's not showing as changed in the XI web interface for me but if I go into the backend Nagios Core interface it's showing that notifications are disabled.

Please login to the backend nagios Core interface at the URL below with that user's credentials, click on Services on the left, and view the service and confirm if it shows notifications are disabled there ike that on yours as well and I'll dig into it further on my end:

Code: Select all

http://YOURXISERVER/nagios/

EDIT: I have confirmed this looks to be a bug on displaying but does indeed disable it on my end, bug report submitted:

Code: Select all

NEW TASK ID 15715 created - Nagios XI Bug Report: XI - Regular user disabling notifications on hosts/services they are a contact of not showing as disabled in the XI web interace/Core shows properly

[atc0005]

Hi ssax,

Thanks for the reply.

Interesting, it's not showing as changed in the XI web interface for me but if I go into the backend Nagios Core interface it's showing that notifications are disabled.

Are you referring to logging in as a non-admin user who is a contact for the host/service? Once logged into the XI interface you disable notifications for a host or service check and XI isn't showing it as disabled, but when you login to the Core interface you see that it is actually disabled?

NVM, I just read your edit:

EDIT: I have confirmed this looks to be a bug on displaying but does indeed disable it on my end, bug report submitted:

CODE: SELECT ALL
NEW TASK ID 15715 created - Nagios XI Bug Report: XI - Regular user disabling notifications on hosts/services they are a contact of not showing as disabled in the XI web interace/Core shows properly

Thanks for submitting that.

Did you receive an error or did the change attempt in the XI interface just not "show" any changes?

[ssax]

I logged into XI with the regular user, clicked Disable Notifications and the command was successful but the XI web interface didn't update (indicating it didn't work based on it still showing as enabled in the XI interface for that user)

Then I logged into the backend Nagios Core interface which doesn't use the database and it showed it as disabled in that interface.

Re-enabling does the same thing, the commands work but the XI web interface doesn't show it properly even though it's actually disabled if you look at Core.