PowerShell Universal 2026.3 - Official gMSA Support and Recommended Installation Configuration

PowerShell Universal 2026.3 - Official gMSA Support and Recommended Installation Configuration

avatar
wwong1

We are an existing PowerShell Universal Enterprise customer from Ironman Software and are currently planning/upgrading our deployment to PowerShell Universal 2026.3.

We would like clarification on Devolutions' current support stance and recommended configuration for using a Group Managed Service Account (gMSA) with PSU.

Specifically, can you confirm the supported and recommended configurations for the following?

  1. Running the PowerShell Universal Windows service itself under a gMSA
    • Is this officially supported in PSU 2026.3?
    • Are there any known limitations compared with running the service as LocalSystem?
    • Are there specific Windows rights, filesystem ACLs, registry permissions, or other configuration requirements that should be applied?
  2. Using gMSAs for RunAs / automation execution
    • Is the recommended model to run PSU itself as LocalSystem and use separate gMSAs for scripts, endpoints, or jobs that need domain access?
    • Can RunAs gMSAs be used when the PSU service itself is running under another gMSA or traditional domain service account?
    • Are there any restrictions on this configuration in 2026.3?
  3. Secret Management
    • Are there known limitations with PowerShell SecretManagement / SecretStore when the PSU service runs under a gMSA?
    • Does the built-in PSU secret functionality fully support a gMSA service identity, including after automatic gMSA password rotation?
    • Are there any vault types or configurations that you recommend or specifically discourage when PSU runs under a gMSA?
  4. Known-good / recommended installation pattern
    1. If available, could you provide the currently recommended enterprise deployment pattern for PSU 2026.3 where domain resources such as Active Directory, SQL Server, file shares, etc. need to be accessed?


For example, is the preferred architecture:
LocalSystem -> PSU -> RunAs gMSA(s) for privileged/domain actions

or

PSU gMSA -> domain resources directly
or another configuration?

I have reviewed the documentation and searched the Ironman Software forums. There are several older discussions where users report successfully using gMSAs, including password-less RunAs credentials, but there also appear to be issues or caveats around the PSU service identity, RunAs behavior, and Secret Management.

Before we standardize our 2026.3 installation, we would like to understand the officially supported and tested configuration from Devolutions, rather than relying on older community posts.

Thanks.

All Comments (3)

avatar
rubentapia

Hello @wwong1

Thank you for the detailed questions and for outlining the deployment patterns you are considering for PowerShell Universal 2026.3.

The current documentation covers several parts of gMSA usage, including service account permissions, RunAs scenarios, and some Secret Management limitations. However, it does not provide enough detail to confidently answer every aspect of the architecture you described, particularly around the officially recommended deployment pattern for PSU itself running under a gMSA, the interaction between service identity and RunAs gMSAs, and the preferred Secret Management configuration in that scenario.

Rather than making assumptions based on older forum discussions or incomplete documentation, I am going to verify the unclear points internally so we can provide you with an accurate answer for PSU 2026.3.

The main items I will confirm are:
• Whether running the PSU Windows service directly under a gMSA is an officially supported and recommended configuration in 2026.3.
• Whether LocalSystem with separate RunAs gMSAs is preferred over running PSU itself under a gMSA for domain resource access.
• Any current limitations involving RunAs gMSAs when PSU itself is already running under another service identity.
• The recommended Secret Management approach when PSU runs under a gMSA.
• Any additional Windows rights, ACLs, or configuration requirements that should be considered for an enterprise deployment.

Once those points are clarified, I will update this thread with the confirmed guidance.

Best regards,
Ruben Tapia

avatar
rubentapia

Hello @wwong1

Thank you for your patience.

We have raised the remaining gMSA architecture questions internally so we can provide guidance that accurately reflects the intended behavior and recommended configuration for PSU 2026.3.

At this point, we will wait for that internal clarification before providing a definitive recommendation regarding the PSU service identity, RunAs gMSA usage, and the appropriate Secret Management configuration.

I will update this thread as soon as we have the confirmed guidance.

Best regards,
Ruben Tapia

avatar
wwong1
Hello @wwong1

Thank you for your patience.

We have raised the remaining gMSA architecture questions internally so we can provide guidance that accurately reflects the intended behavior and recommended configuration for PSU 2026.3.

At this point, we will wait for that internal clarification before providing a definitive recommendation regarding the PSU service identity, RunAs gMSA usage, and the appropriate Secret Management configuration.

I will update this thread as soon as we have the confirmed guidance.

Best regards,
Ruben Tapia


@rubentapia

We look forward to Devolution's response. We will explore migration to the new platform using a traditional service account model while the team gathers some clarity.