Nimsoft Architecture – Data segregation considerations for MSPs
We have customer servers hosted at two different locations, so they are under two different Hubs. I have managed to configure settings so they can view their robots under respective Hubs but I want to hide all other Hubs as well. So only ‘WXYZ’ hubs/robots should be seen and all other hubs are invisible.
NMS User 'Types'
If you don’t want your customer to be able to see your Hubs:
Caveats: Since CustomerA needs to be able to administer their own infrastructure and/or control what their users can access, they will need Superuser/Administrator access and therefore will ALSO be able to see your NMS users.
"We also do not want our customers to even see the Archive (ISS Root, License), Application, URL in the bottom of the window."
Problem: ABC was able to see ALL MSPx Hubs.
Solution: Configure ACL, e.g., ABCGlobal_Admins (copy SuperUser settings) on MSPx primary hub with Infrastructure filter set to ABCGlobal hub name so NO ABCGlobal users can see/access MSPx hubs when they login. Also, deselect User Administration permission for the ABCGlobal_Admin ACL and add filters for the infrastructure (see hub/alarm filtering below).
Caveats: Since ABC needs to be able to administer their own infrastructure and/or control what their users can access, they will need Superuser/Administrator access and therefore will ALSO be able to see MSPx NMS users.
Note also that ACLS can be created on the MSPx primary hub that allows “Other” Administrative users (non-Superuser) , e.g., AdminLevel1, to have more limited control as per the ACL settings, e.g., no permission to access to Extended Security, Execution levels 1/2/3, or even Create, Modify, Delete Users. UMP access/permissions are controllable in the same way using ACLs per each NMS user.
MSP - sample policies
If ABC will be adding hubs/Robots, MSPx should recommend default Robot settings that should be adhered to so as to avoid Robots/QoS data not showing up in Dynamic Views.
Additionally, MSPx will need to assist ABC when adding hubs unless ABC agrees to use a consistent naming convention, e.g., hub1-ABC_hostname or something similar so that MSPx can for the ACL; define a single Infrastructure filter on the primary hub at MSPx preferably - to cover all hubs (existing/new),e.g., using wildcards/regex. As long as the naming convention is known and stays the same it will allow ease of deployment for ABC without assistance from MSPx.
Since MSPx wants to ensure that ABC doesn’t see MSPx alarms, Alarm filtering can also be implemented within the ACL. One of more hubs can be specified for the ACL under “Set Alarm Filter” in the Hub window and one or more hubs can be specified using regex/wildcards/ and OR symbols (pipe), e.g., hub1-ABC.*|hub2-ABC.*|hub3-ABC.* etc.
Further details/information below:
Normal UMP Users
You add NMS 'users' from the Nimsoft Infrastructure Manager via Security->User Administration. Once they are added in IM you should be able to login to UMP using their login ids.
User Administration and access
Users can be associated to ACL’s and ACLs are used to control access within the Nimsoft Windows Clients like the Infrastructure Manager and Service Level Manager to lock users/groups out of specific area. This may be setup in a very granular fashion. Note that the fields used for controlling access do support both pattern matching and regex. Users created via User Administration can be used to log into the Unified Monitoring Portal and this is the recommended area to add user accounts for enterprises when data segregation in the UMP isn’t a concern.
In all cases when working with an Enterprise or Managed Service Provider (MSP) where they need to restrict data and alarms from specific users, then you need to use 'Account Administration.' (Account-Contacts)
MSPs and 'multi-tenancy'
If you have or add the Account Administration portlet in UMP and then create an Account for your customer or workgroup, assign it the relevant Origin for the servers you wish them to be able to see and then you can add users and passwords in this Account (as Contacts). This is the way which you should add users in a multi-tenancy environment. Otherwise you can do this from Infrastructure Manager, Account Administration-> and add an account and add contacts from there. UMP reads directly from the Infrastructure Manager for Accounts and then duplicates a local account name after the user logs in for the first time.
Defining ownership/origins for users
The origin (data owner) that is assigned to a user, defines which alarm data and QoS data the user has access to. Origins are set for Accounts in the Ownership list, and all Contacts under an Account will therefore have the same ownership to the data.
To set ownership for LDAP users and Nimsoft users, you need to create an Account and define the applicable ownerships, and then link the Account to an ACL. When Nimsoft users and LDAP users that are attached to the ACL, are logging on to the Nimsoft Unified Monitoring Portal (UMP), they will be treated as Contacts in the linked account and get access to the data from the origins you selected (via checkbox) for the account. Each origin is associated with a particular customer hub and is selectable in the Infrastructure Manager when you are configuring access.
Please refer to the Infrastructure Manager help doc for more information: