Granular Node Management Rights.

[#1]

There needs to be a simple way to assign users specific node management rights. For example, i have a group of users that i only want to be able to unmanage nodes, nothing more. There may be sophisticated ways of achieving this but it would be nice to have it built into the "Manage Accounts" section.

Thanks for considering this.

[yervillageidiot]

Improvements to Node Management needs to happen for Solarwinds to maintain its place as the primary enterprise systems monitoring tool for us. A global enterprise with dispersed IT support and management teams needs the ability to silo certain tasks while opening up some tasks to share workload in maintaining the solution in a cohesive and secure manner.

This conversation began in 2012. With the added features to view and control processes, all of the additional functionality that SAM and AppInsight brought to the table node management rights was pushed to a greater point of relevance and concern for us.

[djobrien]

Would be nice to have so our NOC can handle scheduled maintenance without the ability to delete nodes.

[cahunt]

I agree, for us it is different groups or Skill set levels.

[Gary.Musgrave]

I would also like to see a granular permission to be able to allow at least viewing of Audit Event Information.  At present in order to give someone access to this you have to give them full Administrator Rights.

[Network_Guru]

I've reviewed most of this long a$$ thread, but in case I missed it, I will add my 2 cents:

Very few products on the market have a true "Admin" role.

What I mean by this is there is no separation between user management and tool management.

The admin role implies the administration of users and RBACs of the product and NOT management of the tool itself.

I want to give what Solarwinds calls "admin" access to some users, but I want to maintain control over the addition of users & AD groups.

This functionality must be separated to allow compliance with industry standard security models, as well as adding auditing functionality.

(who changed what permissions for what users when).

As for the other suggestions to improve granularity of the actual tool functionality, I agree more is needed.

I believe I was the first implementer of this many years ago, as per this thread.

This allowed only certain users to edit custom properties based on their ability to "clear events".

[tigger2]

Personally:

Any icon or click-able item  in the "Management" section in the node view (or any other class/object, if there are any?) should be restrict-able using the account limitations.  Currently these are at the top of an accounts settings (" Allow Node Management Rights", etc, but I would think they would belong in "Orion General Settings" (or make a new section called "NPM Settings") )similar to how SAM permissions are set.  Then I could set each item to be "No" or "Yes" or "View Only" like the SAM "Real-Time Process Explorer" option.

[cahunt]

I understand this may be an extensive account setup/management overhaul, but I am surprised that this has not yet made it to the 'What we are working on.' Status. Head Chiefs must be able to manage their tribes.

[devin.dao]

This list is exactly what I need.  I don't want to give some individuals in at my place manage nodes right and able to configure almost everything.  This will really narrow down what they can do.

[Dr_Zoidberg]

Just adding my 2p's worth, but being able to allow users to put nodes into an unmanaged state is essential for us.

We use NCM to monitor our customers' networks, and some of them are very obsessive about maintaining accurate uptime statistics.
If they need to take down a device, they insist on the ability to set it to unmanaged beforehand which is a reasonable request.

I don't want to give them full node management rights as then they can add and remove devices at will, and could cause all kinds of problems doing so as they don't know how our alerting rules are configured. We also have a contractual limit on the number of devices we will monitor for them, and we don't want them to be able to bypass this without our knowledge.

At the moment the only way we can do this is for them to log a call with our servicedesk which is far slower than allowing them self service on the maintenance mode option.

[scott.mwa]

Setting permissions for this for various teams is currently a nightmare for me right now.