Cant use RunAs while service account is set

I have a similar issue with 5.5.3 I guess.

I set up PSU with a service account, also following the requirements in the documentation.
Additionally, our service account is a gMSA as well for obvious security reasons.

When I want to run a script with “RunAs” with a dedicated gMSA account - every script as its dedicated gMSA service account in our environment I get an error that I have to run under local system to use gMSA in RunAs.

However, I couldn’t find any restriction for that in the documentation. Also the “AI” in docs. only points out that you have limitations for vaults variables and

Additionally, when working with gMSA accounts, you must ensure that both the machine and account have been granted access to the gMSA account according to Microsoft’s guidelines.
To grant the necessary access to a gMSA account in PowerShell Universal, you must first ensure that both the machine and the service account have the necessary access to the gMSA account. Follow Microsoft’s guide to properly configure this access. Once that configuration is complete, you then need to create a new credential within PowerShell Universal’s secret management. Select the Password Not Required option and enter the gMSA account details (for example, in the format domain\user$ ). With the proper privileges assigned to the hosting account, jobs can then be executed under the gMSA account.

Did you find any solution for this issue?

Having the same problem. Just want to link my thread to this issue here:

Product: PowerShell Universal Version: 5.6.13 I had been running PSU in my prod environment as the local SYSTEM account, and my instance connects to an external SQL database for state management. However, as I was building my dev server, I was instructed by the database team NOT to use a local SYSTEM account to access the database, so I am being forced to use a service account to run PSU. This would be fine, except it is now creating a lot of problems. I am getting a 404 error when sending requ…

Any luck yet?

Personally, PSU should run as the SYSTEM account. No need for any gMSA mumbo-jumbo. The ONLY reason for gMSA is to access other servers. IMHO: That is a security breach. It was a dumb idea that should be tossed out. Its truly insecure. Use CyberArk or a Secrets safe and specify credentials.

If we run as System how do we connect to our MS SQL DB sitting on another Windows Server ?

For some users, a domain account with permissions to SQL is the correct choice. For others, they may work with multiple domains, or, in general, may want higher levels of security, then a domain account running the PSU service is not the the best choice.

There are endless examples of how to connect to SQL server using credentials (account with password). SQL can be configured to use domain accounts, or to use local SQL accounts. Because we have multiple domains, local SQL accounts are a better option for us.

So, then the issue becomes accessing the credentials securely and not having them stored as plain text. PSU supports using Microsoft’s Secret’s Vault and that can work for many users. That has its own risks/issues though, so we elected to use CyberArk where credentials are stored on another CyberArk server using an API safe. To access the credentials, each PSU server’s IP must be approved and they must have an SSL cert that has been authorized to access the accounts. Try to access the safe from a server with an unapproved IP: denied. Try without authenticating using the correct SSL cert: denied. The traffic between servers: encrypted.

So, our PSU code to access SQL server uses the CyberArk API to get the SQL account on-demand and its provided as part of the connection string to SQL No account is actually stored on any PSU server.