Get-SwisData powershell script password safety

I need to run powershell commands/scripts against Orion in order that our patching server can mute and unmute alerts.

Unfortunately, in that script the user name and password is thus visible.

What is the best way around this please?

I believe the script will be executed by the system account of the patching server so I will likely need to attach some form of credentials to the connect-swis command.

Grateful for any advice please.

Find more posts tagged with

Accepted answers

All comments

dan_jagnow

See the Get-Credential documentation and this advice for options that allow you to securely manage credentials with PowerShell.

msknight

Many thanks for this. I guess the remaining question on this is that I'm going to have to create an account in Orion to handle this. What's the minimum I can give such an account in order to allow it to mute and unmute objects please?

jm_sysadmin

I completely agree, also look at Using a certificate to encrypt credentials in automated PowerShell scripts | Chris's Blog — It's called thinking... go with it! (cgoosen.com)
I am going to throw some other stuff out there to think about.

First, for Microsoft patching we don't mute alerts. Our down node alert gives 10 minutes down until it triggers, and since our servers normally come back quicker than that, we just fire off patches and if something triggers our alert it is a non-standard event that we want to review.

Now maybe you need to mute the alerts. Say you have physical servers that take a long time to boot, or you just don't ever want to alert when you patch. Do you have set maintenance windows? I have found that this is great for lots of stuff, but if you do, then build that schedule into the alert window. Stuff that breaks will trigger the alert at the end of the down time, and life resumes normally. This way if servers/services aren't available after your window you have tracked that impact, but nothing 'counts' in the agreed upon timeframe.

Next, you maybe be able to execute the script on the Orion server and use the Connect-Swis -Certificate to get the authorization, you would obviously also need to give the patching system rights to connect to Orion to runs scripts. I haven't done exactly this, but I expect its possible.

Personally, I think you might be able to skip the script, and just adjust the alert to find something that you can live with.

msknight

Good suggestions and it might have to come down to allowing more time in the alert, however I suspect the management might not like that.

We are an emergency service, so suggestions like delaying notification times make management twitchy.

Some large Windows patches do take some time to come back and a few of them nearly give me heart failure by sitting there with the whirring dots and encouraging me not to turn the computer off, before then finally giving me a percentage counter.

I've launched the query at the provider of the patching solution also, so hopefully they'll have some suggestions. This is going to be quite the head scratcher!

jm_sysadmin

Most of the long running whirly dots screens still reply to ping so Orion says its up. Some app monitors might not come back as fast.

Also for systems that can't be down, we require that the system has HA an HA design. The separate servers get patch in different maintenance windows. If an app doesn't support that implantation, its not reasonable for to expect IT to have a better outcome. Its a negotiation with the business, I hope it works out so IT doesn't get noisy alerts.

KMSigma.SWI

Allow Node Management is all you should need. You can further lock this down by applying account limitations (Only allow account 'api-NetworkNodeMgmt' to manage 'Cisco' devices or the like).

If you leverage account limitations, then you are probably best served by putting the 'things' to be managed into Groups and basing the account management around the Orion Groups. The good thing about the Groups is that you don't need to manually update them - you can use dynamic queries to put things in there for you. So if 'new' elements are added to your monitoring, they can automatically be added to the groups and the accounts with the proper rights can do whatever they need.

KMSigma.SWI

I've thought about this a bunch over the years and I want to add a few other options as I see them - these are from my experience as an Orion Administrator, not a SolarWinds representative. Each comes with their own limitations, restrictions, and difficulty quotient, so try and understand each of them.

Certificate Authentication

An option I've only ever tested in a trusted, private lab is using a certificate for authentication. Since the PowerShell API can authorize with the -Certificate parameter, I exported (with private key) the "SolarWinds-Orion" Certificate from the Orion server and imported it to a workstation's. Then I could authenticate from that workstation with the Certificate,

However - this also comes with some big warnings and you should review them with your security teams about possible implications.

Warning 1 - the certificate is used to handle many, many, many things and should be protected more diligently than any username/password combo

Warning 2 - the certificate authentication behaves as the "system" account within Orion, so any changes authorized by this has COMPLETE access (no account-based limitations are honored)

Warning 2.1 - because authenticating this way is the "system" account, it's very hard to differentiate (in the events and logs) if something was done by the Orion services themselves OR by something behaving as the services.

Warning 3 - this is not a supported authentication type for long-term working as the certificate may get updated/replaced on upgrades.

Although this technically works, it's far from the best solution. There are multiple others, so do your research before choosing one and implementing it.

Secrets Management within PowerShell

A much better solution would be to use the new Secrets Store modules that are available in PowerShell. (PSGallery / GitHub) I worked with the pre-release versions of these and they showed some real promise, but I haven't written anything about them on THWACK because they were in pre-release and were likely to change before becoming officially released.

Letting AD do the Heavy Lifting

If you running in a Windows environment, don't sleep on adding an Active Directory account to Orion and letting AD handle the pesky authentications. It's also a way to keep those secrets safe elsewhere. You'd execute the script as the authorize user and connect with the -Trusted parameter (instead of a Username/Password combo).

That Thing I Did Years Ago

When I was young and didn't know what I know now (both about PowerShell, Secrets Management or the Orion API), I used to save the username in a text file within a folder and the password in a text file in another folder. The password was obfuscated by doing bit shifts, base64 encoding, pseudo-encrypting with salts/keys, and other such. Then those folders had explicit permissions applied and the files and folders were encrypted using the native Windows NTFS encryption. It wasn't fool-proof, but it was a decent setup considering the limitations of the time.

Recommendations on Accounts

Insofar as account setup, I'd recommend that any external system that needs to use the API have it' own account (api-Automation, api-IPManagement, api-NodeManagement, etc.) and have crazy complex passwords. Those can be protected in any way that @dan_jagnow mentioned or through some other Secrets Management system.

Your Next Steps

Have a frank discussion with your security team about the good and bad of each of the options. Do the homework and go into the discussion with as much information as you can about how you want to handle the next steps before someone goes rogue and chooses one that might have security implications.

My (personal) Next Steps

I'm going to try and dedicate a little of my time over the next few weeks to working with the Secrets Management PowerShell module and see if I can't come up with a good document outlining the process. Since it's reached an official release state, I think it's time to invest the time.

jm_sysadmin

Secrets store is a great suggestion!