Administer > Configure Security > Determine Your Security Strategy

Determine Your Security Strategy

By default, NNMi Security works in the following manner:

  • NNMi assigns all nodes to the Default Security Group.
  • NNMi operators and guests can see all discovered nodes and all incidents, because of the default Security Group Mappings:

    Tip NNMi administrators always see all nodes and incidents, no Security Group Mappings are required for NNMi administrators.

NNMi administrators can limit access to nodes and incidents by deleting the default (out-of-box) Security Group Mappings. Then no operators or guests can access any nodes until an NNMi administrator explicitly adds new, more restrictive Security Group Mappings. When these out-of-box Security Group Mappings are removed, the predefined NNMi User GroupNNMi User Groups are those User Groups provided by NNMi. Users cannot access the NNMi console until their User Account is mapped to at least one of the following NNMi User Groups: NNMi Administrators, NNMi Level 2 Operators, NNMi Level 1 Operators (with more limited access privileges than Level 2 Operators), and NNMi Guest Userss provide access to the NNMi console only, rather than to the NNMi console and to all nodes. See Remove User Groups from Security Group Mappings for more information.

Security Group Mappings have three settings:

  • User Group identifies the NNMi users.
  • Security Group identifies a set of nodes (and indirectly their hosted objects).
  • Object Access Privilege determines the level of access that each User Account in the User Group has to the nodes in the associated Security Group.

Each node is associated with one and only one Security Group. NNMi operators and guests can view a node only if one of the User Groups to which that NNMi user belongs is associated with that node's Security Group.

When NNMi discovers nodes in your network environment, Tenant and Security Group settings are established in the following manner:

  • Discovery Seeds: If Nodes are discovered as Discovery seeds, the NNMi administrator specifies a Tenant for each Discovery Seed. When NNMi administrators define a Tenant, they specify an Initial Discovery Security Group. Any newly discovered Node within the defined Tenant is assigned to this Security Group. NNMi administrators can change either the node's Tenant or Security Group assignment or both at any time.

    Nodes assigned to the Default Security Group are visible from all views. To control access to a device, assign that device to a Security Group other than Default Security Group.

    Nodes within one Tenant can each be assigned to different Security Groups, and Nodes within one Security Group each be assigned to different Tenants.

  • Auto-Discovery for Default Tenant: When you configure Auto-Discovery Rules, NNMi assigns any Nodes discovered using those Auto-Discovery Rules to the Default Tenant and whichever Security Group is currently configured as the Default Tenant's Initial Discovery Security Group setting (the Default Security Group out-of-box).

Virtual machines: (NNMi Advanced) When NNMi discovers a virtual machineA device that utilizes components from multiple physical devices. Depending on the manufacture's implementation, the virtual machine may be static or dynamic. hosted on a hypervisorThe virtual machine manager in charge of delegating various aspects from a pool of resources to become virtual devices. The delegations might be static or dynamic, depending on the manufacture's implementation. The type of virtual machines being generated depends on the manufacturer's implementation., NNMi assigns the Node for that virtual machine to the same Tenant as the hypervisor. The virtual machine Node is assigned to the Initial Discovery Security Group for that Tenant.

NNMi administrators can change either the node's Tenant or Security Group assignment or both at any time.

If the Tenant for the hypervisor changes, the Tenant for the virtual machine Node does not automatically change.

Global Network Management: (NNMi Advanced) Regional Managers forward information about Nodes to the Global Manager. The Global Manager's copy of the Node object has the same Tenant assignment as the Regional Manager's record of that Node.

In a Global Network Management environment, best practice is to have the NNMi administrators for the Global Manager and all Regional Managers agree to a predefined list of Tenant names. Those Tenants would be defined on the Regional Managers, the Tenant definitions exported, and those Tenant definitions imported onto the Global Manager (thus ensuring that the UUID and name value for each Tenant match on both NNMi management servers). The NNMi administrator on the Global Manager update their Tenant definitions to assign Initial Discovery Security Group values that make sense for the Global Manager's team.

If a Regional Manager forwards information about a Node to the Global Manager, and that Node is assigned to a Tenant object that does not exist on the Global Manager, NNMi creates a Tenant with the UUID and name from the Regional Manager, but creates a new Security Group with that Tenant name (does not duplicate the Regional Manager's setting for that Tenant's Initial Discovery Security Group setting). NNMi maps that new Security Group to the following:

  • User Group = NNMi Administrator
  • Object Access Privilege = Object Administrator

The Global Manager's NNMi administrator can assign a different Initial Discovery Security Group to a Tenant definition at any time. From that point onward, the NNMi Global Manager uses that new Initial Discovery Security Group setting when creating new nodes within that Tenant.

Node revisions: NNMi administrators can change the Node's initial Security Group assignment. See Methods for Assigning Nodes to Security Groups.

Tip NNMi administrators can use Security Groups in Node Group definitions that become filters in NNMi views. If a user cannot access any nodes in a particular Node Group, that filter dynamically disappears from the filter selection list in the user's NNMi views. See Specify Node Group Additional Filters for more information about Node Group filters.

Security influences incidents:

  • Network operators and guests can view incidents associated with a node only if that user's User Account is mapped to one of the User Groups that are mapped to the node's Security Group. See About Security Groups and About Security Group Mappings.
  • Any incident that does not have an associated node is assigned to the Unresolved Incidents Security Group and NNMi's out-of-box configuration makes these incidents visible to all User Groups. Examples of incidents that are unresolved include unresolved traps, system health, and license violation incidents.
  • Operators should only be assigned incidents for nodes they can access.

The following examples present possible Security strategies. Consider printing one or more of the following topics to use as a tutorial about configuring NNMi Security. The Configure Security Tasks table explains all possible choices.

These strategy examples use the Security views under the Configuration workspace (see Using the Security Folder):

These strategy examples use the Security Wizard under the Configuration workspace (see Using the Security Wizard View):

Configure Security Tasks
Task Description
Determine your Security strategy.

Use the guidelines in this Help topic to understand how to configure Security for your network environment.

You must also determine your users, their Object Access Privileges, and the nodes each user should access:

Control Menu Access

User Groups Provided in NNMi

Determine which NNMi User Group to Assign

Remove the Default Security Group Mappings to NNMi User Groups

Out-of-box, NNMi assigns all Nodes to the Default Security Group and all NNMi users can see all Nodes.

To ensure that none of your NNMi operators or guests can see nodes assigned to the Default Security Group, remove these out-of-box Security Group Mappings.

Note Deleting a Security Group Mapping does not delete the associated predefined NNMi User Group nor the Object Access Privilege definition.

Configure User Accounts You must create a User Account for each NNMi user.
Configure Additional User Groups

The NNMi administrator can create any number of User Groups to meet the needs of your network environment.

Examples of when additional User Groups are needed include the following circumstances:

  • When you need a subset of users to access only a subset of nodes.
  • When you need to divide node access between two or more User Groups (such as multiple shifts or multiple sites that share responsibilities).
Map User Accounts to the Predefined NNMi User Groups

A particular user cannot access the NNMi console until their User Account is mapped to at least one of the following predefined NNMi User Groups:

  • NNMi Administrators
  • NNMi Level 2 Operators
  • NNMi Level 1 Operators (with more limited access privileges than Level 2 Operators)
  • NNMi Guest Users

Note NNMi provides two additional User Groups:

  • NNMi Global Operators (secondary)

    Assigning users to this secondary group, in addition to the user's currently assigned NNMi Guest User, NNMi Level 1 Operator, or NNMi Level 2 Operator assignment, provides access to all topology objects, but does not change any other aspect of their currently assigned NNMi Guest User, NNMi Level 1 Operator, or NNMi Level 2 Operator assignment.

    Users assigned to the NNMi Administrators User Group do not need any secondary group assignment. These users already can access all topology objects.

  • NNMi Web Services Client

    Used only to provide access for software that is integrated with NNMi. See Integrations with and Third-Party Products - for example,  RAMS MPLS WAN Configuration (NNMi Advanced)). Do not use any other User Group for software integrations.

Map User Accounts to Additional User Groups

If you created additional User Groups, map the appropriate User Accounts to each User Group you created.

Configure Security Groups

By default, all operators can access all nodes discovered by NNMi. However, the NNMi administrator can limit visibility to a subset of nodes for some or all operators by using User Groups and Security Groups.

Note Each node can be mapped to one and only one Security Group.

Examples of when you need to create additional Security Groups to limit node access include the following circumstances:

  • When you need a subset of users to access only a subset of nodes.
  • When you need to divide node access between two or more User Groups
Map Security Groups to User Groups

After creating any additional User Groups, you map each User Group to a Security Group and assign the Object Access Privilege for this Security Group Mapping. The Object Access Privilege determines the level of access that each User Group has to the nodes that are visible.

Users can view a node only if one of the User Groups to which they belong is associated with that node's Security Group.

Assign Nodes to Security Groups

Out-of-box, NNMi Security settings allow all NNMi User Groups to access nodes assigned to the Default Security Group.

If you create Security Groups to limit node access, you must assign nodes to the appropriate Security Group.

Each node is associated with one and only one Security Group.

Verify Your Configuration Changes

NNMi provides a report that includes information about any of the following potential problems:

  • Users Accounts that are not mapped to a User Group
  • User Accounts that are not mapped to an NNMi User Group
  • User Accounts that have unusual NNMi role combinations
  • Security Groups that include nodes from multiple tenants
  • Empty User Groups and Security Groups
  • Tenants with the same name
  • Security Groups with the same name