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.

Unable to use -Trusted or -Certificate to connect to SWIS on main polling engine

dkeyser over 1 year ago

Hello all,

I'm trying to use PowerShell to connect to the API locally so it can do actions when issues are detected. I'm able to get things working when I pass my account info into the script that won't happen due to security issues with hard coded credentials. I've tried using -Trusted to pass the current user account used to run the PowerShell shell but it refuses. I've tried -Certificate but it doesn't understand it. Error outputs below for context. How do I used these flags? Is there a better way to use the Orion API through the alerting engine?

When using -Trusted: Get-SwisData : The server has rejected the client credentials

When using -Certificate: Get-SwisData : The credentials supplied to the package were not recognized

Top Replies

Parents

0 bobmarley over 1 year ago
I place this at the top of all of my scripts, regardless of if they are run on my desktop or on a server

Import-Module -Name SwisPowerShell Add-PSSnapin SwisSnapin $swis = Connect-Swis -host YOURORIONSERVERNAME -Trusted

If I'm going to run it on my local machine, I just ensure that the AD account I'm logged in is set up in Solarwinds with appropriate rights. Most of the time this is my own personal AD account and I am an admin on my Solarwinds server.

If I'm going to run the same script on a remote machine I log into that machine with an AD service account that has rights to log into the remote machine, and also has appropriate rights in Solarwinds. When launching Powershell I do a Run As and run it as the AD service account. If I'm running it as a scheduled task I run the task as the AD service account. If it is an alert action is also runs as the AD service account.

Never had any issues doing it this way but plenty of issues trying it other ways. Makes it way easier to rotate the account password when you need to, not have to get into your scripts to update the security xml file etc. Hope this helps.
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 bobmarley over 1 year ago
I place this at the top of all of my scripts, regardless of if they are run on my desktop or on a server

Import-Module -Name SwisPowerShell Add-PSSnapin SwisSnapin $swis = Connect-Swis -host YOURORIONSERVERNAME -Trusted

If I'm going to run it on my local machine, I just ensure that the AD account I'm logged in is set up in Solarwinds with appropriate rights. Most of the time this is my own personal AD account and I am an admin on my Solarwinds server.

If I'm going to run the same script on a remote machine I log into that machine with an AD service account that has rights to log into the remote machine, and also has appropriate rights in Solarwinds. When launching Powershell I do a Run As and run it as the AD service account. If I'm running it as a scheduled task I run the task as the AD service account. If it is an alert action is also runs as the AD service account.

Never had any issues doing it this way but plenty of issues trying it other ways. Makes it way easier to rotate the account password when you need to, not have to get into your scripts to update the security xml file etc. Hope this helps.
Cancel
Vote Up 0 Vote Down

Cancel

Children

0 dkeyser over 1 year ago in reply to bobmarley

That's one way to tackle it for sure. I'll evaluate this against our access controls to see if it's a better path to take than issuing a prompt for credentials each time the script is run by someone manually. Though this is great for automatic remediation!
Cancel
Vote Up 0 Vote Down

Cancel