Secret Variables not working when called as a script parameter

PowerShell Universal
1 
Product: PowerShell Universal
PSU Version
5.5.4
Connection String
Data Source=%HOME%/.PowerShellUniversal/psu.db
Repository Folder
%HOME%/.PowerShellUniversal/Repository

I’m currently attempting to build out a new PSU server on Ubuntu and having some trouble with my first automation script. Here are the parameters of the script:

param (
    [Parameter(Mandatory)]
    [string]$Domain,

    [string]$IPAddress,

    [parameter(Mandatory)]
    [PSCredential]$Token
)

I have a PSCredential secret set up like this:

image
image855×708 21.1 KB

Then, when running or scheduling the script, I use these parameters:

image
image739×428 4.36 KB

Every time I run the script, I’m getting this error:

image
image479×181 5.41 KB

This seems pretty straight-forward - what am I doing wrong here?

Thanks all, it’s good to be back on this forum after a long hiatus!

2

You can’t (at least, that I’m aware of) use a PSCredential for app tokens since you only have a hash (the token) and not a username/password. You can store your token as a Secret variable instead, but you’d need to execute your script in a user context under an identity that’s got access to read the Secrets entries in order to do that.

I would suggest providing the token in your query in a literal string rather than trying to reference it dynamically as a parameter, personally, similar to how you’d do it in any other public API query.

For example, create an app token that’s tied to an identity with access to run whatever it is in PSU that needs to be accessed, then add that token as a passed parameter to your PSU endpoint (API) or whatever it is you’re running.

If you were using CURL, you could have something like:

curl --location --request POST 'https://<PSU-FQDN>/<PSU-Endpoint>?Domain=<domain>&IPAddress=<IPAddress>&Token=<Token>' \
--header 'Authorization: Basic <Base64 Hash of PSU identity to authenticate to the API with>' \
--data ''
3

Not sure what you mean - the docs say you can create a secret variable as a string or a PScredential object. And when I assign a value to the script patameter, I’m offered the choice of the credential variable I created. So from my perspective I can’t see any reason why parameter binding would fail here.

4

Do you get the same error if you try to run the script from Scripts? You schedule might not have permission to get the secret:

1 Like
5

Well, I kinda blew it and after I couldn’t figure this out I tried to uninstall PSU and then reinstall it. Now I can’t get it running again. I just did this with Uninstall-PSUServer and then re-ran Install-PSUServer, all with no additional parameter values. Now when I try to login I get the error:

SQLite Error 1: ‘no such table: Identity’.

I’m not sure what to do now, I’m guessing maybe some artifacts from the original installation are hanging around. I’ll keep poking around to see what I can figure out and then get back to this original question.

Brief answer to your question is - yes, I believe I was getting the same error even if I just tried to launch the script rather than running the schedule. I can’t currently confirm that, though.

6

I’ve had re-install issues on Windows before, and I had to uninstall again, remove the folders below, and reinstall:

%ProgramData%\PowerShellUniversal
%ProgramData%\UniversalAutomation

Based on your original post, the location of the first folder would be %HOME%/.PowerShellUniversal/Repository for you, but I’m not sure about the second one.

1 Like
7

You’re a lifesaver! I had to dig through and do a find of any PowerShellUniversal files and folders, but I was finally able to remove all the artifacts and get this running again. I’ll do some testing and see if I can recreate the variable issue.