I am not sure this is the intended way this works, but trying to find a workaround. Setup
Running psu on iis under local system account. Problem
Secure Variables work if the script is running default Credentials. If I change the “run as” for a script I can not access any of them any more. I need to have the script “run as” due to connecting to SQL with AD credentials as sql does not allow you to pass AD auth to it. I need to also use Secure Variables to retrieve API keys to connect to other things.
The documentation says " Values for secrets with the BuiltInLocalVault are stored within the Windows Credential Manager instance of the security principal that is running PSU" It looks like even run as accounts effect this, not just the account the psu service is running as.
What would be the best way around this. Can I add secrets to the run as account? . If so what is the best way to manage them as I assume they will not be in PSU.
Reading thought the documentation i am also a little confused. We ran as local system due to this line in the iis install IIS - PowerShell Universal
" App Service configured as Local System - Scripts will execute as the System Account by default and a Run as AccountsCAN be specified when executing a Script in Universal Automation"
but in the run as documentation it says the opposite. Is this one just for non iis install? Running as a Service Account - PowerShell Universal
“The PowerShell Universal application can be run as a Service Account. This means that the application will run all of its functions as the service account, including local application tasks, jobs (by default), and dashboards. This is a suggested configuration and is REQUIRED to execute jobs as other PSCredentials defined in Secret Variables.”
The only thing I can think of is create an API that runs as the service account, then pass the sql statment to it to execute and return the data. Is this the best way or is there something better?
Mike
This is a current limitation of the secret management solution in PSU. We currently only access the secrets in the current process and not over the RPC channel between the server and the jobs. I’ll open a feature request (or bug?) for this as I think we should be able to do so and it’s not obvious why it’s not working.
The problem at the moment is that most PS secret management vaults are user specific. Even ones like Azure Key Vault store the vault information in a user specific way even though the secrets aren’t even stored locally.
Can I ask how you are executing SQL (dbtools or something?) I mainly ask because I am pondering workarounds.
sqlserver module with invoke-sqlcmd. From what I was researching yesterday it did not look like there was any way to pass AD creds to sql. Only sql creds. Very interesting this is not a feature. I will have to see about using a local sql account for now but this goes against our standard.
Thanks for the reply and help,
Mike