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

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

Parents
  • I have this same issue and to date haven't identified a fix. My workaround is to use certificate locally (its a bad practice as it has limited audit trails) and switched most my scripts to run from remote hosts to avoid hitting the problem...

    The interesting piece is if you specify the same creds manually it works. It's just an issue with the Trusted option. I'm happy to open a ticket on this one...

    I'll add though if you're unable to use -Certificate that may be another issue when running local.

    Are you using the latest version of the SwisPowerShell powershell module and what version of Orion are you using?

  • I am currently using the -Certificate switch at this time. Seems to be working as intended when pointing at a secondary Orion server.

  • I spoke too soon it seems. I wasn't getting any errors but further investigation is showing the same error message as before when attempting to use -Certificate "Get-SwisData : The credentials supplied to the package were not recognized". Haven't put in one of the domain service accounts into Orion as a user yet but that might not be possible. That -Certificate flag seems like the win for me but it's not working.

  • There is the other option of using an encrypted XML file. See below.

    Also when running Powershell at least in my environment I right click on it and do Run as a different User and launch Powershell with an administrator account (that is also in Orion)  if I'm not logged onto the machine as an admin account

    #Using an encrypted XML file for 
    
    #Run the line below a single time to create an XML file with your secured credentials in it. 
    #Run it in the same directory your script will reside in
    #Place your Orion user where shown below EnterTheOrionUserNamehere
    #Correct the path C:\PowershellScripts\ to whatever path you are using
    Comment out the next two lines after you have run this once
    GET-CREDENTIAL –Credential "EnterTheOrionUserNamehere” | EXPORT-CLIXML C:\PowershellScripts\SecureCredentialsSVC_OrionWMIProd.xml
    Exit (0)
    
    
    Cls
    Write-Host "Loading Solarwinds Plug in"
    Import-Module -Name SwisPowerShell
    Add-PSSnapin SwisSnapin
     
    #On the line below replace EnterTheOrionUserNamehere.xml with the name of the XML file created above
    #Also correct the path C:\PowershellScripts\ to whatever path you are using
    $MyCredentials=IMPORT-CLIXML C:\PowershellScripts\EnterTheOrionUserNamehere.xml
    
    #Enter your Orion server name here
    $ORIONSERVERNAME = 'YOURORIONSERVERNAME'
    $swis = Connect-Swis -Credential $MyCredentials -host $orionservername
    

  • Certainly lots of creative (and trivial storage of) ways to pass credentials into scripts in PowerShell that could be used to workaround this issue for sure. Good to share none-the-less as it could be very useful for others here.

    I myself use -Trusted all the time dynamically as I tend to work in PowerShell frequently to do all sorts of tasks.

Reply
  • Certainly lots of creative (and trivial storage of) ways to pass credentials into scripts in PowerShell that could be used to workaround this issue for sure. Good to share none-the-less as it could be very useful for others here.

    I myself use -Trusted all the time dynamically as I tend to work in PowerShell frequently to do all sorts of tasks.

Children
No Data