• State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 24 subscribers
  • Views 753 views
  • Users 0 members are here
Options
Related
This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Preventing creation of subnets outside of a supernet

seg

I work for a large organisation which has chosen to utilise Solarwinds IPAM for organisation-wide management of address space. We're running IPAM version 4.3.2 - upgrading will be difficult to achieve here, but if it absolutely had to happen maybe it could... eventually.

I'm responsible for the network of one business unit (let's call it BU1) of this company (there are about 4 business units) and my BU (BU1) has been allocated a block of private address space (10.8.0.0/16) to do with as we please.

What I'm trying to figure out is if it is possible to create a supernet in a manner that prevents other IPAM users from creating subnets which belong within that Supernet. I can't currently test this myself as the permissions on the server are so broad (and applied globally, not on the individual groups/supernets/subnets in the tree) that all users can create groups, supernets and subnets anywhere - but if it's possible, I can try to get the server admins to change the global permissions config to facilitate this.

To elaborate - if I create an address group, and a supernet within that group, then lock down the permissions on the group and the supernet so that only members of "BU1 admins" can modify and create entries within that structure, will IPAM prevent someone from "BU2 admins" creating a subnet which belongs inside "my" supernet, elsewhere in the structure? I feel it should, but I have a bad feeling it might not.

Our IPAM structure looks something like this: (heavily simplified, but enough to demonstate the issue - the below is much cleaner than the reality here)

  • IP Networks
    • BU1 [group]
      • 10.8.0.0/16 [supernet]
        • Site A 10.8.1.0/24 [subnet]
        • Site B 10.8.2.0/24 [subnet]
    • BU2 [group]
      • 192.168.0.0/16 [supernet]
      • 172.16.1.0/24 [subnet]
      • 172.16.2.0/24 [subnet]
      • Metro Sites [group]
        • 10.12.0.0/16 [supernet]
          • Site C: 10.12.1.0/24 [subnet]
    • BU3 [group]
      • 172.16.3.0/24 [subnet]
      • 10.10.0.0/16 [supernet]
      • Metro sites [group]
        • Site D: 10.14.1.0/24 [subnet]

So back to the scenario - I'm responsible for BU1's address space, 10.8.0.0/16. I believe I can lock down the permissions (by removing the global config permissions and instead applying permissions at the group level) so that only members of "BU1 admins" can create supernets, subnets and groups inside the BU1 section. But if I do this, will it prevent someone from creating an allocation of say 10.8.10.0/24 inside BU2/Metro Sites? This is a subnet of 10.8.0.0/16 and right now, it's possible to create a subnet of that supernet anywhere in the structure (which doesn't make sense to me) - I need to prevent from happening - is IPAM smart enough to know that if the permissions on the 10.8.0.0/16 supernet are locked down, subnets of that supernet cannot be created by people who don't have permission on the 10.8.0.0/16 supernet structure?

  • 0

    If I am understanding your question correctly, and believe that I am, you should be able to accomplish this using the IPAM nested permissions.  It sounds like you have AD Groups configured for SolarWinds logins - An AD Group for BU1 Admins and one for BU2 Admins.  You would go to Manage Accounts and Edit permissions for BU2 Admins.  Scroll down to near the bottom of the screen where you will see nested permissions for each module that you own (and that have nested permissions - IPAM is a module that does).  From there, you can set permissions per group/supernet/subnet.  So you could give BU2 Admins read-only permissions to your BU1 IPAM address group and then read/write to their BU2 IPAM address group and then vice versa for BU1 Admins. You can make a user a Global IPAM power user, operator, read-only, or custom.  You would choose custom, and then it takes you to the screen where I took a screen shot where you can set permissions for the user per group/supernet/subnet. Note that we are running IPAM v4.7.0 and if you don't see the IPAM nested permissions, like the screen below, it could be that your older version doesn't support these permissions.  If my memory serves me correctly, IPAM v4.3.2 should support them.

    pastedImage_0.png

    Regards,

    Parker Robinson

    Loop1

  • 0 in reply to jpr7311

    Thanks Parker. I think these types of permissions are what I want to apply.

    Do you believe that if I do this, SolarWinds will prevent "BU2 Admins" (who have RO access to my folder/supernet structure) from creating a subnet within their BU2 structure which belongs in my 10.8.0.0/16 supernet? (e.g. 10.8.1.0/24)

  • 0 in reply to seg

    The BU1 Admins will not be admins anymore since they will have a custom IPAM role that will define per each Group,Supernet or subnet the type of access it will have.

    pastedImage_0.png

    When you try to add a subnet as one of the BU1 you can only add subnet from the parent supernets that you have RW access to. If for exampel BU1 tryes to add the subnet 192.168.4.0/24 he will get this error:

    pastedImage_1.png

  • 0 in reply to bogdan.stan

    Excellent, thanks. This is exactly how I was hoping it would work.

    In this case it sounds like the current 'sloppiness' in subnet enforcement is more around the overly broad permissions assignment which has been setup here rather than a lack of functionality in IPAM - which makes me happy. I'll start planning some config changes.

    Also unfortunately I can't mark both answers above correct so Bogdan gets it for the very specific detail which left me without doubt - thanks Parker however as I'm sure your intent was the same and your answer is also helpful.

SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 195,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.

SolarWinds Customer Success Center Certification Media Vault Link Accounts
About THWACK Blogs For Government Edit Settings Free Tools & Trials
Legal Documents Terms of Use Privacy California Privacy Rights Security Information
©2024 SolarWinds Worldwide, LLC. All Rights Reserved.