Effects of Limiting Object Access

Configuring NNMi security has the following impacts:

• Topology inventory objects:

  • Each NNMi console user sees only those nodes that match the configuration for their NNMi user account.
  • Sub-node objects, such as interfaces, inherit the access control from the node.
  • Inter-node objects, such as connections, are visible only if the NNMi console user can see at least one of the nodes involved.
  • A NNMi console user sees only those node groups for which they can access at least one node in the group.
  • For Network Performance Server (NPS) reports, the NNMi administrator can selectively override access control inheritance on interfaces. For more information, see Including Select Interfaces in NPS Reports.

• Maps and path views:

  • Maps show connections for which the NNMi console user has permission to view both of the participating nodes.
  • Path views omit or show as clouds any intermediate nodes to which the NNMi console user does not have access.
  • For the NNM iSPI for MPLS and the NNM iSPI for IP Multicast, when maps and path views include nodes to which the NNMi console user does not have access, the NNM iSPI displays only the connecting interface and the name of the node. The icons for the inaccessible nodes are white to indicate that status and detailed information are not available for these nodes.
  • For the NNM iSPI for IP Telephony, when maps and path views include nodes to which the NNMi console user does not have access, the NNM iSPI displays only the connecting interface and the name of the node. The icons for the inaccessible nodes show the NNMi status, but all attempted actions fail.

• Incidents:

  • For incidents whose source node is in the NNMi topology, an NNMi console user sees only the incidents for which the user has access to tho source node.
  • Incidents that do not have a source node, such as NNMi health and licensing management event incidents, are handled as a group. The NNMi administrator determines which NNMi console users see them (by associating the users with the Unresolved Incidents security group).
  • Incidents that result from traps for which the source node is not in the NNMi topology are handled in the same way as incidents with no source node. If NNMi is configured to generate these incidents, the NNMi administrator determines which NNMi console users see them (by associating the users with the Unresolved Incidents security group).

  Note The incident assignment action does not check user access. It is possible for an NNMi administrator to assign an incident to an NNMi console user who does not have permission to view that incident.

• NNMi console actions:

  • For actions that run without any selections, an NNMi console user sees only those actions they have permission to run.
  • For actions that run against one or more selected objects, an NNMi console user must have the correct access level to the selected objects. Depending on the security configuration, the NNMi console might present actions that are not valid on some of the objects visible in the NNMi console views. Invoking one of these actions results in an error message regarding this limitation.
  • For map views and NNM iSPI table views and forms, NNMi cannot distinguish between unknown nodes and nodes that exist in the NNMi topology but are not accessible by the current user.

• MIB browser and line grapher:

  • An NNMi console user can view MIB data and graphs for nodes to which they have access.
  • An NNMi console user can view MIB data for nodes to which they know the SNMP community string.

• NNMi console URLs:

  Users must log on to NNMi before accessing an NNMi console view from a direct URL. NNMi enforces that user’s access according to the NNMi security configuration and limits the available topology accordingly.