Product: PowerShell Universal
Version: 4.2.21
I have a specific Jobs environment that has access to all the platform variables, run by a JobAdmin user as Administrator role, all the secrets are restricted to the Administrator role and stored in the Database, but when the schedule fires off the script it stops and prompts for the password to the PSUSecretStore. I didn’t think the secrets were even using the PSUSecretStore since they’re all stored in the database.
I did check the appsettings.json and the SecretStore password and Database encryption key are still there and have not changed compared to the previous 3 backups.
Screenshots of everything can be found here.
What am I missing? Are my secrets corrupted somehow?
Thanks
@afranco Just to make sure, you are using a custom appsettings.json file, and aren’t referring to the default appsettings.json file that’s located in the install path’s root folder, right?
That does seem odd, though, that you’re being prompted for the SecretStore password when the secrets are set to be stored in the Database. Maybe @adam can explain that one.
I didn’t know there was a separate appsettings.json to be honest, I’ve only ever used the one located at C:\Program Files (x86)\Universal\appsettings.json.
1 Like
While both do technically work, the one in the install path root gets overwritten by upgrades (see here for more details), which is why they tell you to use that one as a template to create the other located at C:\ProgramData\PowerShellUniversal\appsettings.json with any custom settings (such as changing ports, Git repository settings, etc.). Settings in THIS file take precedence over any settings in the default appsettings.json file.
I’ve been just merging the new appsettings.json with the backup I take right before doing the upgrade 
Have it saved in $env:ProgramData\PowerShellUniversal\appsettings.json now. Thanks for the tip!
After a service restart, still have the same issue though. I removed the SecretStore secret from my appsettings, since they all should all be in the Database anyways, and it doesn’t prompt for it anymore, but now it just doesn’t find the $Secret:VOIPAdministrator and fails to run.
It works no problem if I run it manually under my permissions, but the JobAdmin doesn’t have permissions to view it for some reason.
@afranco You don’t maybe have duplicated roles that are both named Administrator, or something, do you? You’d think that PSU would prevent such a thing, but it doesn’t (at least, not entirely). It does, when dealing with custom roles you’ve already added (at least from my testing), but if you try making a new role with the same name as one of the built-in roles, it will have created a duplicate role even though it doesn’t show in the Web UI. You can only see it when viewing the roles.ps1 file. So, if you accidentally created another Administrator role at some point, there’s maybe a chance one identity got assigned to the built-in role and the other identity got assigned to the custom role. You can check the roles.ps1 file to be sure. It’s located at C:\ProgramData\UniversalAutomation\Repository\.universal\roles.ps1 by default.
I’ve filed a bug for the duplicate role names, for the record.
So I don’t have duplicate roles defined in roles.ps1, however I did find something odd in authentication.ps1. I have this line at the bottom
Set-PSUAuthenticationMethod -Type "WSFederation" -Disabled
Which strikes me as odd because we do use WSFederation. The Web UI at /admin/security/authentication shows WS-Federation enabled via appsettings.json. Might not make any difference since everyone in my org is able to use SSO with no complaints and the JobAdmin user is marked as a Local Account, but maybe something there?
I do have roles.ps1 establishing an LDAP session with our domain and looking for members of an AD group to determine what role they are assigned, but also have the local identity for JobAdmin assigned to the role so shouldn’t matter if JobAdmin is in my AD or not.
1 Like
Which appsettings.json shows WS-Federation being enabled? I’m assuming both do, unless you only moved over the settings that you want to be different from their default values (which is really all that needs to be in the appsettings.json file that goes to C:\ProgramData\PowerShellUniversal\appsettings.json - it doesn’t have to contain everything the default appsettings.json file has in it, though there isn’t harm in doing so.
I just copied the whole appsettings.json over to C:\ProgramData\PowerShellUniversal\, I just won’t copy the settings back after I do the next update
1 Like
Well, that is definitely strange, then. Sounds like something is corrupted to me but I’m not sure where to start.
I stopped the service, removed the below files, started the service, and recreated all the secret variables. Getting the exact same result though. Runs just fine when I run it manually, but when the JobAdmin runs it on the schedule it fails to find the $Secret. Don’t think its a database or secret corruption, unless there’s another file somewhere I missed.
C:\ProgramData\UniversalAutomation\database-log.db
C:\ProgramData\UniversalAutomation\database.db
C:\ProgramData\UniversalAutomation\log.db
C:\ProgramData\UniversalAutomation\Repository\.universal\variables.ps1
@afranco Can you show the output of your environments.ps1 file? I want to see if the custom environment you made is missing -Variables @('*') in its definition. That might be one problem.
Edit: Nevermind. I forgot you shared screenshots.
Removing the -Role parameter from them in variables.ps1 lets JobAdmin access the secrets and run. Doesn’t seem to be the Administrator role at fault, since me and other admins are able to run scripts using the secrets, so I recreated the JobAdmin user account. Still no luck
Any ideas @adam?
That does seem to suggest it’s just a bug and not anything you’ve done or corruption.