Option to change Windows Service-Account of Gateway Service
1 vote
Hi!
Regarding Installation on a Windows Server it would be good to have a supported option to define another gateway service account than NETWORK SERVICE.
For example - session recording to SMB-Share requires authentication. It is actually possible to access a share and use it for session recording when changing the gateway service account to one that has access to that share.
But there are caveats:
- you need to manually adept NTFS permissions for the gateway folder within "Program Data" for the new service user
- triggering gateway update from devolutions server/RDM fails (ERROR listener{port=7171}:https{client=xx.xx.x.xxx:61728}:request{method=POST path=/jet/update}: devolutions_gateway::http: error=500 Internal Server Error at devolutions-gateway\src\api\update.rs:68:9: failed to write the new `update.json` manifest on disk [source: Access is denied. (os error 5)]))
- everytime you modify the gateway-configuration from the server console (companion tab), the service-account automatically changes back to NETWORK SERVICE
BR
All Comments (2)
Hi!
We recognize the need for a better supported workflow here. As per internal discussions, we are looking into:
- Updating the installer to ensure it does not overwrite a custom service account on updates.
- Providing documentation about the required permissions for a custom Windows service account running the gateway.
We’ll keep you posted on any progress for official support and documentation.
Best regards,
Benoit Cortier
Hello @stefannitsch-fitz
I've been looking at this issue and I had hoped to make some changes for 2026.1.3; I'm not sure if that's still feasible but I'll keep you posted and at the latest we'll probably be looking at 2026.2 (next month).
There are a few things I want to clarify with you, based on the work I've already done.
First, you wrote
everytime you modify the gateway-configuration from the server console (companion tab), the service-account automatically changes back to NETWORK SERVICE
Are you sure this is accurate? The reason the service account gets updated is that the Windows MSI treats every update as a "major upgrade" (versus a patch). In Windows Installer, this means that the existing product gets uninstalled and then the new version gets installed, rather than just replacing the updated files. So the service is recreated in this scenario and the user account customization gets lost.
The thing is, I don't see another path that can happen and it shouldn't happen by editing the configuration. Can it be that you actually mean this happens when updating Gateway by the console? Or perhaps when you noticed this, it coincidentally happened at the same time as an update? Please let me know, because if what you say is true then further investigation is needed.
Secondly, can I ask what kind of account you're using for Gateway? Is it a well-known account (e.g. LOCAL SERVICE), a virtual account, or maybe a gMSA / MSA? The key with those kind of accounts is that they don't need a password. If you're using a regular Windows / domain account (which as I understand it, would not be recommended) things are more complicated because it's harder to support an upgrade path without needing to re-specify the password on every upgrade (that may not be so bad for manual updates, but is much more complicated via DVLS or Agent).
I understand the problem with the other issues you've raised.
Please, let me know if something isn't clear
Kind regards,
Richard Markievicz