Monitor NNMi Access

NNMi provides several tools to help you monitor NNMi access and role-based security configuration.

Check Security Configuration

Each NNMi user can be assigned to multiple Security Group Mappings. The Object Access Privilege determines what NNMi users can do with a node object. For example, if their User Group is NNMi Level 2 Operators, but the Object Access Privilege is Object Operator Level 1 (with more limited access privileges than Level 2), each user assigned to the Security Group Mapping sees all of the actions available to a Level 2 Operator, but can run only those actions allowed for Level 1 Operators. If an NNMi user is assigned to multiple Security Group Mappings, that user sees all the parts of NNMi that are provided to the highest User Group setting and access for each node is determined by the node's Security Group Mapping.

NNMi administrators can generate a report of possible Security configuration 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

Generate the report using any of the following methods:

• Tools → Security Report
• The nnmsecurity.ovpl command

You can also use the View Summary of Changes option in the Security Wizard to view a report based on only your latest configuration changes.

View Summary of Changes in the Security Wizard

Use the Security Wizard View Summary of Changes option to view your recent configuration changes, including the following:

• The User Accounts created.
• The User Groups created.
• The Security Groups created.
• The User Accounts and User Groups mappings.
• The User Groups and Security Groups mappings.
• The Security Groups that have new nodes assigned to them.

To view the summary of security configuration changes:

From the Security Wizard main page, select the View Summary of Changes option.

NNMi displays a summary of the configuration changes made since you last saved your changes.

View the Users who are Signed In to NNMi

Use the Tools → Signed in Users menu option to view a list of the NNMi users who are currently signed in to NNMi. This tool is useful when you want to determine which users and systems are available. For example, you might want to view the users who are signed in before shutting down a system.

To see the list of users who are currently signed in to NNMi:

Select Tools → Signed In Users.

NNMi displays the number of users currently signed in to NNMi as well as each user name, IP address of the client that is running the NNMi console, and the time in which the user signed in to NNMi.

Audit NNMi User Sign-In and Sign-Out Activity

NNMi tracks a history of sign-in and sign-out activity for each NNMi user.

NNMi stores the sign-in/sign-out log files in the following directory (see Manage environment variables):

Windows

%NnmDataDir%\log\nnm

Linux

$NnmDataDir/log/nnm

NNMi names these log files signin.log. Any archived log file has a number appended to the end of the file name, for example signin.log.%g.

• signin is the log file base name
• %g represents the archive number of the archived log file

The highest appended archive number represents the oldest file. A log file can become an archived log file after the size of the log file exceeds the configured limit. After a log file exceeds the configured limit, the last active log file is archived. For example, after NNMi archives the nnm.log file as the nnm.log.1 file, NNMi begins logging to a new nnm.log file. Each archive file's name is incremented by one each time a new archive becomes the nnm.log.1.

Audit NNMi User Actions

By default, NNMi audits user actions and user initiated changes to the NNMi database. These kinds of user actions include, but are not limited to, the following:

• Changes to NNMi topology objects (for example, nodes, node groups, interfaces, and interface groups). Examples include creating or deleting Node Groups or Interface Groups, and changing filters or membership in a Node Groups or Interface Groups.
• Changes to incident lifecycle information. Examples include changing an incident's owner or state.
• Changes to user and access information. Example include changing passwords, adding or deleting a user account or user group, and creating tenants.
• Configuration changes made using the NNMi console  Configuration workspace or a command line tool. Example include modifications to SNMP settings, discovery settings, and monitoring configuration.
• User actions from the NNMi console Actions menu. Examples include Configuration Poll and Status Poll.

Example Log Entries:

User Action:

2014-10-26T22:00:21.305 admin 10.12.203.55 ACTION "" com.hp.nnm.ui.actions.configpoll Node 4295011152 cisco4k1 "" "" ""

Model Updates:

2014-04-30T01:20:25.301 joe.operator 10.12.203.55 MODEL abb44ddb-ae52-40d9-855f-f6ab0ab899e1 UPDATE Node 151434 172.20.12.7 managementMode MANAGED NOTMANAGED

2014-04-15T01:55:48.574 admin "" MODEL 4654e06c-5c1f-4955-bf82-e317dcbf38f3 CREATE Account 56647 op1 name "" op1

Each record in the audit log includes the following kinds of information:

Audit Log

Field	Description
Timestamp	When the audit record is created. In ISO-8601 format without a timezone (local time).
Username	The logged in username associated with the change.
Remote Address	For changes made via the NNMi Console this will be the address of the client system: The remote address of the client if applicable. "" (indicates not applicable).
Record Type	The category describing the type of change: ACTION – An action run by the user. ACCESS_DENIED – A security check was performed and the user was denied access to the specified action. MODEL – A change to an object in the NNMi topology or configuration made by the user. MESSAGE - Log messages about the system rather than auditing of a user action. For example, the following series of messages might be logged when auditing has successfully begun and is subsequently stopped: 2015-08-24T22:37:01.012 system "" MESSAGE "Auditing started" 2015-08-24T22:37:01.014 system "" MESSAGE "Reloaded auditing configuration; auditing is enabled" 2015-08-24T22:37:01.015 system "" MESSAGE "Audit service initialized successfully" 2015-08-24T22:59:08.194 system "" MESSAGE "Audit service shutting down" 2015-08-24T22:59:08.195 system "" MESSAGE "Auditing stopped" TX – Used to indicate transaction boundaries for very large changes. If a change has a very large number of entries then it is written progressively as changes are made and these entries will indicate if the transaction commits or rolls back.
Transaction ID	Used to correlate multiple entries into a single transaction. Populated for all MODEL entries: ID "" (indicates not applicable).
Operation / Action	The specific operation or action associated with the entry. "" (means no action performed) For MODEL record types: CREATE – Creating an entry in the NNMi database. UPDATE – Updating an entry in the NNMi database. DELETE – Deleting an entry in the NNMi database. For TX record types: BEGIN – Records the start of a transaction. A matching COMMIT or ROLLBACK should appear later in the audit log to indicate the outcome of the transaction and all changes made within it. COMMIT – The transaction committed and so all entries associated with that transaction in the audit log have been applied. ROLLBACK – The transaction rolled back and so all entries associated with that transaction in the audit log were NOT applied. For ACTION record types this entry contains a code indicating which action was performed by the user.
Target Object Type	When the record pertains to a type of object in NNMi this entry lists that type: For example, “Account” for a change to a user account. "" (if not applicable)
Additional meta data available for the object or action (if applicable):
Target Object ID	When the record pertains to a specific object in NNMi this entry lists the unique ID of that object. "" (if not applicable)
Target Object Name	When this record pertains to a specific object in NNMi this entry lists a user-friendly name or label of that object (where available). "" (if not applicable)
Field Name	When this record pertains to a specific field on an object this identifies the field that was changed. For example “password” might be the field if the object type was “Account”. "" (if not applicable)
Field Previous Value	When this record pertains to a specific change to a field on an object this entry lists the previous value of the field. Sensitive information such as passwords values are displayed as asterisks, for example: password ************ Create operations will have an empty value ("") in this position. Delete operations will have the value before delete in this position. "" (if not applicable)
Field New Value	When this record pertains to a specific change to a field on an object this entry lists the new value of the field. Sensitive information such as passwords values are displayed as asterisks, for example: password ************ Create operations will have the initial value in this position. Delete operations will have an empty value ("") in this position. "" (if not applicable)

The auditing log files reside in the following directory (see Manage environment variables):

• Windows:
  %NnmDataDir%\nmsas\NNM\log\audit-<date>.log
• Linux:
  $NnmDataDir/nmsas/NNM/log/audit-<date>.log

See also "NNMi Auditing" in the Network Node Manager i Software Deployment Reference at https://softwaresupport.softwaregrp.com/ for more information.

Restore the Administrator NNMi Role

If you have accidentally configured NNMi so that zero NNMi users are mapped to the 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 Users: NNMi Administrators (preventing anyone from being able to access the Configuration workspaces), access the NNMi console as the system user to correct the problem.

Sign into the console using the password that was configured for the system user when NNMi was first installed.

If you do not remember the password assigned to the system user, use the nnmchangesyspw.ovpl command to reset the system user's password.

Restore NNMi Access for the system User

NNMi provides an nms-roles.properties file that stores part of the system user configuration. This file is located in the following directory:

• Windows:
  %NnmDataDir%\nmsas\NNM\conf\props\nms-roles.properties

• Linux:
  $NnmDataDir/nmsas/NNM/conf/props/nms-roles.properties

You should not need to ever modify this file.

To verify the contents of this file:

1. With a text editor, open the nms-roles.properties file.

2. Verify that the following required line is present:

   system = system,admin

3. Save and close the file.