Submit a ticketCall us

Training Class Getting Started with SolarWinds Backup - February 28

This course offers customers an introduction to SolarWinds Backup, focusing on configuring the backup technology, taking backups, data restoration and data security. It is a great primer and will get you up to speed quickly on SolarWinds Backup.
Register for class.

Home > Success Center > Archive > 2018Jan03 - Deletes > 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 Kevin.Swinson on Jan 04, 2018

Views: 785 Votes: 0 Revisions: 5



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


All Orion versions


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