This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Inner workings of the Orion audit databases?

Hello,

In lieu of granular unmanagement rights I have been tasked and thus working on a secure means of allowing for select people to modify the unmanagement details of specific nodes.  My method will be a relatively simple PowerShell script that has some security checks (Does this user have the ability to unmanage node X?), and if it passes them it modifies the UnManaged, UnManageFrom, and UnManageUntil details for that node row in the Nodes table of the database.

However, I'd like for such actions to also show up in the audit log of Orion.  Would this be as simple as adding a new line to the AuditingEvents table with the proper ActionTypeID, NetworkNode, and NetObjectID or is there more to it than that?

Can anyone shed some light on how the backend of the audit events is actually structured and functions?

  • Do not try to modify the Database directly.  Use the Orion SDK.  Go here for more information http://thwack.solarwinds.com/community/labs_tht/orion-sdk

  • If I unmanage a node using the Invoke-SwisVerb PowerShell cmdlet of the Orion SDK wouldn't the user account I use need administrative access assigned in Orion?  If so, this method doesn't really help me.  I need a way for users to manage/unmanage nodes who aren't admins in Orion, and instead must pass a custom security check instead.

  • Upon further prodding it, while the Orion SDK is fantastic from a programmatic perspective it still suffers the same limitations in terms of the lack of granular access rights that the web interface has.  Does the SDK allow for the editing of audit events by chance?  I could have an obfuscated set of credentials that the script uses to actually perform the unmanagement and then alter the audit entry with the actual username if that were possible.  However, I'm guessing "change the audit table" isn't an SDK function.

  • I may have settled on a best of both worlds.  This still falls under a "this isn't entirely supported by SolarWinds" model, but it seems to work with no issue.

    What I've done and am currently testing is (in a nutshell) using PowerShell to invoke the SDK using credentials added to Orion.  Then, the script follows up, and runs a stored procedure that simply is:

    UPDATE [SolarWindsOrion].[dbo].[AuditingEvents] SET AccountID = @Username WHERE AccountID = 'unmanagescriptuser'

    This does amount to modifying the database, but doing so hasn't seemed to break anything so far in my test environment.  Searching by username still works, all the links work, etc.  It's certainly far less hostile to the table than my initial thoughts of inserting a brand new row into it.