PowerShell remoting is kind of magical (which is another way of saying complicated and error-prone!).
But I suspect the actual problem here is that the exported SecureString is not portable from one computer to another. So when you copy the long number produced by ConvertFrom-SecureString and paste it into the remote session, it can't be decrypted properly. When I try that, I get this error:
ConvertTo-SecureString : Key not valid for use in specified state.
I know you are trying to do the right thing and protect that password, but try using a plain text password to see if you can get it working:
ConvertTo-SecureString “Hello” -AsPlainText -Force
If that works, then you can either live with the plain text password, get Windows authentication (the -Trusted option for Connect-Swis) working, or look at the -Key option for ConvertTo/From-SecureString (of course, then you have another secret to protect somehow...).
Thank you for that information, it slipped my mind that
there would be keys involved to do the SecureString generation. The plain text
method works perfectly as you describe. My next step was to attempt generating
the securestring text on that remote computer, but it looks like the encryption
is tied to the user account and the local computer generating the string.
My intention of having someone else run this script wouldn't
work unless they generated the secure string beforehand. Even still, you need
to set-up SPN's/delegation to even generate the string. You would think
double-hop authentication would be more straightforward in passing tickets
around but I’m sure there are technical reasons that it isn't seamless yet.
We ended up creating a local solarwinds account so the plain
text password would really just give these people access to solarwinds and
nothing more. It isn't the end of the world if we have to store the password in