Since upgrading to 5.0.5, none of the secret variables are being read by any of the scripts. I tried creating a new secret just to test with, and then made a script that does Write-Output $Secret:testvariablename to see what it would do, and there is no output at all. No error, either. I also noticed that when typing out $Secret: into a script, there is no longer a window showing possible names to choose from.
Product: PowerShell Universal
Version: 5.0.5
What vault are you using? I just tried with the DB vault and my secrets show up in scripts.
As for IntelliSense, I don’t think we ever had completion for secrets unless you had used them previously in the script.
Unless v5 doesn’t use the same default key that v4 used (because I never changed it to a custom key), I can’t see why secrets wouldn’t be working post-upgrade.
I thought I recalled IntelliSense, but I could be wrong.
The default key didn’t change. If you create a new secret does that one work? Did you have to do a DB conversion at all?
The secret variable in the screenshot I attached above is a new variable I made to test with, and it doesn’t work either.
Test.ps1 just has a single line in it:
Write-Output $Secret:JesseTestSecret
This is what I see when it runs:
No. We started on v4, so we were already using SQLite.
@adam I figured it out and fixed it.
In v4 and lower, in the custom appsettings.json file you would set your custom database path as:
"Data": {
"ConnectionString": "filename=%ProgramData%\\UniversalAutomation\\database.db"
}
In v5, this apparently needs to be changed to:
"Data": {
"ConnectionString": "Data Source=%ProgramData%\\UniversalAutomation\\database.db"
I don’t recall seeing anything about the value needing to be changed from filename= to Data Source= but maybe I overlooked it. Either way, changing it to that is now allowing PSU to access the DB properly and I can pull Secret variables.
I’m on 5.0.11. My appsettings file already has the “data source”, but I’m unable to access the secret from my scripts. The secret is accessible from the dashboard when using it directly. The script runs as a user with Administrator access, at least that’s what shows up when I do a “whoami”. I don’t have a user defined in the “Execution” settings for the script. The only way to retrieve the secret is to disable any Roles assigned to the secret. If this is unrelated to what your problem was, please let me know and I’ll start a new threat.
Where are you using your script (in a scheduled task/job, in an API (Endpoint), etc.?
Depending on the context, you would also need to authenticate to the PSU server with an account that has access to the secret(s) you need to reference, such as by using Connect-PSUServer at the top of your script.
The script is running from “Scripts”. The script is trying to hit a secure Endpoint, so I need to pull the secret. The Endpoint can be reached from the App where the script is initialized from using the same secret. But the script can’t read the Secret. I’ve tried just running the script with a write-host “List secret: $($Secret:SomeName)”. This just shows "List Secret: ". If I turn off authentication for the secret it shows the secret.
How is the script being called, though? You said it works when run manually (which is because you’re logged in and it’s running it with your credentials), but fails when it’s run other ways. What other way is it being run where it’s failing? Is it being called by a scheduled job, or is it being triggered as part of a PSU endpoint (API)?
You’d need to provide some sort of credentials to authorize the script to have the appropriate rights to access the variables, and that’s typically done by creating an App Token tied to an appropriate user/identity, and then using Connect-PSUServer at the top of your script to authenticate.
The script is being called from a PSU App.
The script/job (whatever we wanna call it since they’re all essentially scripts) does not retrieve the credentials when run manually if authentication is enabled on the secret variable.
The secret can be retrieved from the Application’s .ps1 file though. Is that because it’s running under my usernames context?
When I run the script with a “whoami”, it returns the service account used for running the PSU Service in Windows. The service account has local admin access to the machine. Maybe an important point is that it’s a Group Managed Service account, gMSA.
I tried adding a credential in the script settings under “Execution” that has rights to the secrets variable, but that gave me a different error.
I guess I’m wondering what the expected behavior is?
When I’m in an app, does it use the end user context or the service account?
When a script (from Scripts in PSU) is run, does it run as the service account?
When an Endpoint is run, does it run as the service account or end user?
Why do I have to run connect-PSUServer if I’m already on the server? I’ve never had to do that before…
Thank you, and I know this might be out of scope for this thread.
Correct.
If you’re referring to pre-5.0.x versus post-5.0.x, you are correct that the behavior changed. You can read more about that here and here.
So, as I mentioned, if you generate an App Token based on an identity that has access to the secrets (for example, your own login), and then use that with the Connect-PSUServer cmdlet, the script would run with the same level of access your account has.
So, at the top of your script, you’d have something like:
$AppToken = <redacted>
Connect-PSUServer -AppToken $AppToken -ComputerName 'https://<redacted>'
Thank you, I will try this solution.
@Lundholmster Not a problem. Hopefully it solves your issue.
But is this a safe way of doing it? I’m typing out the apptoken which has access to the secret in clear text in the script?
Or is this secure because the script where the apptoken is written out in is locked down for certain roles only?
I created a secret with the apptoken in it, but I had to remove the security for the apptoken to be able to read it. It only has read rights to run an API, so it’s not a big deal in this case, but is there a more secure way of accessing secrets securely without having to add an apptoken string in clear text in the script?
Thank you!
Not until @adam or his team add a way to define a token globally, like inside of the appsettings.json configuration file, unless I’m forgetting something. This is the method that most of us have had to use for our own setups (at least for now). Only admins should be able to view scripts, so if you can’t trust your admins, I’d say there’s bigger issues to worry about.