Access Control queries (zones/find IP/inheritance/multi-select)

Started by normalcy, February 03, 2016, 04:14:50 AM

Previous topic - Next topic

normalcy

Hi, is it possible to enable multi-select editing of access control lists in the object browser?  So for example you could select a range of subnets and apply group/user permissions to all at once instead of one-at-a-time editing of properties > access control?

I'd like to grant access to branch office users to view some subnets but not others within a zone under entire network and infrastructure services to allow them to find IPs connected to ports, and see L2/L3 maps of devices currently online (technical sales reps in branch offices who are always asking for the status of various devices and what's plugged into their showroom switches etc). 

It also seems that if you use zones and want to be able to use "tool > find IP address" from a non-admin user you must grant read access to the zone object (to allow zone choice in find IP address dialog).  However by enabling read access to the zone this inherits read access rights to all subnets under that zone by default.  To remove the visibility of the other subnets for the branch user group then requires editing each subnet object manually to remove inheritance and add ACLs.  Would be easier with a lot of subnets to allow multi-object (shift-select) editing of permissions.

As an example I have a setup similar to the following and would like an easy way to restrict subnets 2~4 to user group for branch 2 without having to manually edit each subnet object under entire network one at a time and remove inheritance from parent and put in additive and negative ACLs for each branch group on every subnet (doesn't scale as number of subnets gets higher). 

entire network
---Zone1
------subnet 1 (branch 1)
------subnet 2 (branch 2)
------subnet 3 (branch 2)
------subnet 4 (branch 2)
------subnet 5 (branch 3)
------subnet 6 (branch 3)
...
------subnet n (branch n)

infrastructure services
---branch1
------racks
------switches
------routers
------devices
------PCs
---branch2
------racks
------switches
------routers
------devices
------PCs
---branch3
------racks
------switches
------routers
------devices
------PCs


eg:  At the moment to enable a group for branch 2 to see only subnets 2~4 I have to enable read access to the zone to allow find by IP to work, then on each subnet record (could get to hundreds) right click and edit properties and remove inheritance, and add in an allow rule for branch 2.  As more branches/subnets get added rinse and repeat.

I guess it would be great (and for all I know there already is a way to do this!) if netxms could allow either:

  • Multi-select editing of some properties in the object browser (eg: shift select 10 subnet objects, right click on properties and change access control for all 10 subnets at once)
  • Current inheritance seems to be upward looking toward parent.  Would it make any sense to allow a checkbox to block downward inheritance to child objects too? Or would that break things the other way in that nodes/interfaces now loose permissions and have to be manually edited.
  • Is there a way during discovery (filter script?) to designate some subnets as having certain user/group permissions?
  • Is there a way to use the nxshell to automate applying a lot of ACLs to a lot of subnets at once? (say providing a text list of subnets to have a certain ACL set applied?
  • I suppose one suggestion might be to use a separate zone for each branch and control access there?  None of the branches have separate IP ranges as they're all linked via private LANs and so that's why they're under a single zone, and I've tended to use zones to separate our internal monitoring from a few customers where we monitor some field testing equipment they have.

Just looking to avoid a lot of point and clicking in the interface before I start.

Thanks in advance for any advice all, and thanks for this fantastic software.

Victor Kirhenshtein

Hi,

currently there are no easy way to do what you want except for nxshell scripts. As you have access to full client API in nxshell you can do anything that can be done from management console.

I see two easy to implement options to simplify things in future versions:

1. add "non-inheritable" option to ACL entries;
2. Option to add ACLs to multiple selected objects. While adding can be implemented easily, mass edit could be quite complicated because objects may already have different access right assignments.

Best regards,
Victor