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'
- Real NimBUS Users (defined via IM's 'User Administration'), can login to the Infrastructure Manager (IM) and perform Infrastructure Management/Administrative tasks. Their credentials are stored in $NIMROOT\hub\security.cfg file.
- LDAP-linked users - are the same as real NimBUS users but they are authenticated against LDAP/AD.
- Account-'Contact' users (defined via IM's 'Account Administration'), cannot manage Nimsoft Infrastructure and cannot login to IM but they can login to UMP. Their credentials are stored in the Nimsoft SLM database in CM_CONTACT and CM_ACCOUNT tables.
- NMS Accounts are local to the database hence so is the ability to control Account Views.
- Hence, ACL filters should not be applied to Accounts. Filtering for Accounts is limited to origin-only so ACLs defined for Account->Contacts are limited to origin and nothing else.
- When you need a finer level of filtering for users, you must associate ACLs along with the desired filters, to an NMS user(s) not an NMS Account->Contact(s).
- Contacts in an Account can only see alarms by origin so if you have ACL alarm filters, these filters will NOT apply to Contacts when they log in.
- NMS users see ALL Dynamic Views/Dynamic Reports and alarms (this depends on ACL filter settings)
- Account ACL allows filtering of only the Views (alarms, robots etc)
- Not all UMP portlets are restrictive e.g., RemoteAdmin portlet provides access to non-account hub’s discovery data.
- NMS users: it is give and take on visibility vs. level of control provided to customer. The same security.cfg file syncs across the hubs so they can view the users, provided customer knows the location, even without access to Infrastructure Manager. But, the point here is, it is a best practice to either restrict customers to Account or most restrictive ACL.
- Account/Contacts see ALL Dynamic Views and Reports and alarms linked/controlled by 'ORIGIN.' The Account must have ownership to the origins of the alarms/entries the 'contact' needs to view. Those origins are selectable in the Infrastructure Manager for the Account once hubs have been deployed and data is flowing from the hubs.
- Note also that loginid MUST be unique between User Administration and Account- Administration. Also note that the Account MUST be associated with at least one origin for the 'contact' to be able to login.
If you don’t want your customer to be able to see your Hubs:
- Configure ACL, e.g., for CustomerA (copy the Superuser settings) on your primary hub with the Infrastructure filter also being set to CustomerA Hub’s name so no customer users can see/access your hubs when they login.
- Also, optionally you can deselect User Administration permission for CustomerA’s ACL and add filters for the Infrastructure (see hub/alarm filtering below).
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.
- Note also that ACLS can be created on your 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 NMS user.
- If CustomerA will be adding hubs/Robots, you should recommend default Robot settings that should be adhered to so as to avoid Robots/QoS data not showing up in Dynamic Views.
- Additionally, you will need to assist CustomerA when adding hubs unless CustomerA agrees to use a consistent-standard naming convention, e.g., hub1-CustomerA_hostname or something similar so that you can for the ACL; define a single Infrastructure filter on your primary hub 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 facilitate ease of deployment for you without assistance from Customer(s).
- You may want to ensure that Customer(s) do not see your 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-CustomerA.*|hub2- CustomerA.*|hub3- CustomerA.* etc.
"We also do not want our customers to even see the Archive (ISS Root, License), Application, URL in the bottom of the window."
- There is currently no way of effectively ‘hiding’ the Archive/Applications/URLs in the Navigation Pane. The "Archive" will disappear only if no box is selected in the ACLs. The fields "Applications" and "URLs" are always present and cannot be hidden.
- You need licenses there for all licensed probes running on customer end; this can be avoided by not installing the distsrv probe so that licenses can be checked from the main hub.
- Application links depend on what you install, e.g., IM, SLM etc. so if they aren’t installed locally, then you won’t see them in the Navigation pane 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: