Sometimes it is necessary to store certain information in a (secure) way, like a connection string, which you might want to use in your PowerShell scripts. The scripts could be then used e.g for the Command Notification Channel. Let’s assume you need to connect to a foreign system and this system provides you with a connection string, something like this…
Endpoint=sb://bubu.servicebus.windows.net/;
SharedAccessKeyName=Bubu;
SharedAccessKey=1234567890=;EntityPath=Bubu
…in this case it is a string for connecting to Azure Service Bus. It also could be a database connection string or something similar. The point is, that you don’t want to store this string in your script, for security reasons, so your connection string does not travel around when the script gets copied or maintained etc. What you could do, to have some sort of separation of credential and the script is to store it in a RunAs account. How to do it?
Create a Unix/Linux Run As Account…
Give it a meaningful name…
Next paste the connection string into the User name field and provide a fake password like this …
Choose More secure and don’t configure any computer to distribute this account to…
Now you should have an account like this…
If you want to retrieve the string for using in your PowerShell script do it like this…
And the output of the $ConnectionString will look like this…
Well I know it is not a very secure way for storing information, but in some cases it might make sense to keep the sensitive information separated from the script. In addition it is easily maintainable for administrators, so they don’t need to touch the script. Don’t blame me for any security breaches, it is just a way how you could store such information :). I think Microsoft will not support this kind of hack. Again, it is just an idea and not a way how you must do it.
Why are we using UNIX/Linux RunAs Account? Well the other accounts don’t allow such complex strings to be stored.
Hope this helps…
