Hi,
we are currently planning to migrate our existing standalone Devolutions Gateway to a 3-node Devolutions Gateway Farm.
As part of this implementation, we would like to run the Devolutions Gateway Windows service using a Group Managed Service Account (gMSA) instead of a regular domain service account.
I found official documentation regarding gMSA usage with Devolutions Server, but I could not find a clear statement regarding the Devolutions Gateway service.
Could you please confirm:
I would like to clarify this before implementing the configuration in our production environment.
Thank you! :-)
T
Hello
Currently there's no path to choose a different service account than NETWORK SERVICE. It's hardcoded in the installer. Nothing prevents you from updating the account used by the service post-installation, assuming the account has the permissions it needs, and there's no reason you couldn't use the same gMSA across all Gateways in a farm. The sticking point is likely your last one - the custom service account will currently not be preserved during upgrades and would need to be reconfigured on every update.
Since a gMSA is passwordless, there's nothing that prevents us from updating the installer to preserve the account across upgrades. Equally, we need to document the permissions required by the service account. Those changes should make things more seamless for you. It gets a bit more tricky for your third point: as well as integrating this into the Gateway's own installer, we also need to make the Devolutions Server console aware of this feature. I assume you use the server console to manage your deployment? Or do you use the Gateway MSI directly?
I don't like to answer a question with more questions but there's something to clarify. We have an open feature request right now to support custom service accounts with Gateway, which relates to your question. I haven't tackled it yet because I'm not sure how to meet that customers specific requirements (they want to store recordings on a NAS, which doesn't work for an MSA or gMSA, they need a regular Windows account, with a password, which gets very tricky to preserve across upgrades). Do you plan to use the recordings feature of Devolutions Gateway? What's your plan for storing recordings, if that is the case?
In short, given what you've described, what you want is possible but not very ergonomic. We can easily make some changes on our side to make it more convenient for you, but the scope and difficulty of those changes depends on your answers to my last question.
Please let me know if something isn't clear or you have other questions.
Kind regards,
Richard Markievicz
Hi Richard,
thank you very much for the detailed explanation. This clarifies the current situation quite well.
Our plan is to install and manage the Gateways through the Devolutions Server console, rather than using the Gateway MSI directly.
Regarding recording, we currently do not use the Gateway recording feature and there are no plans to enable it at the moment. From my understanding, recording should also be possible with a gMSA as long as the required permissions to the recording location are granted to the account.
If I understand you correctly, using a gMSA for the Devolutions Gateway service is technically possible today, and the main limitation is that the custom service account is currently not preserved during Gateway upgrades.
If that is the case, we will most likely go ahead with the gMSA approach for our new 3-node Gateway Farm anyway. Having to reconfigure the service account after an upgrade is something we can include in our maintenance procedure until proper support is implemented.
Would it be possible to document the required steps and permissions for using a gMSA with Devolutions Gateway somewhere in the official documentation in the meantime?
This would give us a supported reference for the necessary configuration until full gMSA/custom service account support is implemented in the installer and upgrade process.
Proper integration into the Devolutions Server console and automatically preserving the configured service account during upgrades would of course be the ideal solution in the future.
Thank you again for looking into this.
Best regards,
T
Hi Thomas
I will work on getting that documented and update you once I have some news. It shouldn't be very long.
Thanks for your patience
Kind regards,
Richard Markievicz