Submit a ticketCall us

Announcing NCM 7.7
With NCM 7.7, you can examine the rules that make up an access control list for a Cisco ASA device. Then you can apply filters to display only rules that meet the specified criteria, order the rules by line number or by the hit count, and much more.
See new features and improvements.

Home > Success Center > Network Performance Monitor (NPM) > Multiple success audit events from a service account used in Orion

Multiple success audit events from a service account used in Orion

Table of contents
Created by Eric Bryant, last modified by Rodim Suarez on Jun 27, 2016

Views: 16 Votes: 0 Revisions: 4

Updated

Overview

This article explains a behavior that may be seen when using one or more WMI accounts service accounts for multiple WMI polled nodes.

Environment

All Orion versions

Detail

Security audits on your server may indicate there may be some spoofing or erratic authentication coming from the Orion poller(s) within seconds apart from each other per audit success logs. EventID(s) could range from 4624, 4648 or 4675.

 

Polling intervals in Orion are staggered and depending on the amount of elements (wmi nodes) in the environment could be within 15-45 seconds apart from each other that they will try to authenticate against the domain or local machine depending on the credential used for WMI polling.

 

Standard server monitoring generally utilizes the same domain admin account across all servers to cut down on having to manage many different accounts per server. Since Orion allows you to add the same credential to multiple nodes, it's common for a single account, or a select few, to be utilized on multiple nodes for monitoring. Each one of these nodes will generate an authentication with said account during polling, so it is common to see multiple accounts authenticating to the same node in a very short amount of time.

 

Also keep in mind that this polling occurs per product, per monitoring type. For example: utilizing just NPM and SAM for monitoring a Windows server you would have authentication based off these areas:

- Node details (Memory and CPU utilizing, etc)

- Hardware health

- Node statistics (volumes and interface changes, rediscovery, etc)

- SAM monitoring for application 1

- SAM monitoring for application 2

- Etc..

 

Each individual job for these types of jobs will each generate their own authentication. Since the polling interval for all of these are different, the authentication times can look as though they are coming in gaps or coming in back to back. This is normal behavior.

 

Last modified
18:18, 26 Jun 2016

Tags

Classifications

Public