Account limitations

I'm having troubles with two setups. I'm currently on Orion v10.1. If anyone know how to accomplish the setup please do share otherwise can these please go in as feature request for future releases.

We've got an operations group responsible for adding and removing Orion nodes. They're assigned 'node management' rights. A request has come forth to remove their ability to use Network Sonar. Is there a way to accommodate this request while leaving the ability to add/remove nodes.

I've configured a few dynamic groups under the new tabl "Groups". I'm looking to limit user account views to only see nodes in those dynamic gorup. Currently adding group account limitations only limit views under tab 'Groups'.

Find more posts tagged with

virtual_environment

vmware_esx4_cluster_top10

virtual_server

vmware_esx

vmware_reports

virtual

virtual_machine_details

Accepted answers

bshopp

Chad you are spot on in regards to groups and how those factor into limitations and this is for sure an area we need to improve in. We already have this marked down as something we want to enhance.

All comments

casonline

I'll add to that... I have similar requirements/issues... Some may be by design, or may be bugs...dunno.

I’m running into an issue where I’ve got a group/user set to have node management rights, and I’ve setup an account limitation to limit that is based on a group, say Vmware, which I’ve set as a dynamic group for any h/w or vendor of VMWare. This way as new VMWare hosts are discovered, they are automatically added to the group, and hence the account limitations would allow for this node to automatically show up in our virtualization groups list of nodes w/out me doing anything.

1) The problem I have is that account limitations don’t appear to be working when using a group as the limitation. But when I switch it to limiting based on h/w manufacturer and/or vendor, it appears to work... With a caveat. Manage nodes right also gives manage groups right, which I don’t want, unless I was able to limit a group mgmt right to a specific user/group. And in this scenario, it also gives me rights to manage the virtual infrastructure settings.

Ideally what I’m trying to accomplish is... Distributed node mgmt to the responsible parties. I need to lock down the node mgmt abilities for nodes by group, so that they can manage/unmanage, and the ability manage what’s monitored or not on a node; but I don’t want them to be able to manage groups, or ideally, even be able to add or remove nodes w/out my group (monitoring admins) having a hand in it. We’d be responsible for adding/removing nodes, etc; they’d be able to have limited mgmt of the nodes once added.

2) Additionally, with a limitation set, shouldn’t an account only be able to see groups with nodes in it that they have rights to ? I’m able to see all groups, even if there are no nodes my test account has right to... Probably should have that automatically “disappear” from the view ?

3) when limitations set based on vendor alone, I was able to delete a group, but not a group member, of which I had node mgmt rights to, via account limitations...however, I can delete a node via node mgmt view. So it seems like something is amiss...

4) with the same limitations set (vendor vmware), there is no manage vmware settings on the Virtualization tab, however, because I have node mgmt rights to vmware hosts... When I go in there, I can edit vmware credentials and nodes... I feel this right should be completely separated out as well.

5) also noticed that with this limitation set, in the VIM tab, I can list the hosts in the tree, but don’t list any vmguests under the hosts, presumably because they are not of type “vmware”; however when going into the host details, you can see the vm guests... which appears to be by design..just presents conflicting views on things...I understand why it's doing what it is though... one is a node perspective, the other is a VIM perspective.

I’d like to see more granularity at some point... Particularly with manage/unmanaging nodes/interfaces/volumes, and being able to let particular users/groups manage their assigned nodes in times of maintenance, or adding/removing interfaces and such to/from monitoring. But that would be it. I’d not want them to be able to manage anything else, particularly polling settings, and such, as that could get out of hand quickly and screw up polling all together and kill system resources.

In short - it seems like there needs to be more granularity around admin rights:

Node management – ability to manage/unmange nodes/interfaces/volumes only for maintenance/outages, or schedule outages in some way, while limiting all other aspects of node mgmt.Generic node management rights is a bit too broad in my opinion.. things like setting polling intervals, custom props, using network sonar, etc are giving too much leeway for normal users if we just want them to manage their own outages/maintenance on a node.
VIM management rights should be separated out like node mgmt rights are.
Node mgmt rights, should not allow group mgmt rights necessarily, at least in the case of #1 above...if this granularity were broken out a bit, then it might be ok I think...

As I dive into this, there is more and more popping up very good path you are going down with this... Looks like some things to tweak still...

Chad

bshopp

Chad you are spot on in regards to groups and how those factor into limitations and this is for sure an area we need to improve in. We already have this marked down as something we want to enhance.