Restrict Entry Types in User Vaults (Devolutions Server + RDM)

Restrict Entry Types in User Vaults (Devolutions Server + RDM)

2 votes

avatar

Hi Devolutions Team,
we’re currently using Devolutions Server as our data source in combination with Remote Desktop Manager for connection handling. We have a centralized, global "IT Vault" where no users have write permissions. All entries in this vault are maintained automatically through our system inventory and the DVLS API – this setup works flawlessly for us.
However, we've noticed that some users still create their own connection entries in their personal User Vaults. We'd like to prevent this, as our intention is for User Vaults to only contain credential entries (e.g., personal credentials, 2FA tokens, etc.).
Feature request:
We’d like to request a feature that allows us to restrict the types of entries that users can create in their User Vaults – ideally configurable either globally or based on user groups. Specifically, we’d want to allow only credential entries in User Vaults, while blocking other types such as session/connection entries.
Would this be possible to implement, or is there a workaround available for this use case?
Thanks in advance for your consideration!
Best regards,
Sandro Widmann

All Comments (7)

avatar

Hello Sandro,

Thank you for your suggestion. This is not a product development that is currently planned. Could you elaborate why your users still save entries in their user vault? Is it a connection that you would like them to save in your IT Vault?

We’re taking note of your feedback and will follow this topic to see if there's any additional interest or input from other users.

Best regards,

François Dubois

avatar

Hey,

thanks for the quick reply. Basically, we don’t want any users to manage their own connection entries. We want them to use the user vault purely as a credential manager. The idea is to have fully managed connection handling (IT Vault) based on a large asset database as the data source. DVLS gets everything pushed via API - but only if the assets are properly maintained in the database. So DVLS acts as a kind of enforcement tool to ensure that happens.
If users have the option to bypass this, they will. Of course, we communicate the concept, but if you don’t lock it down technically, someone will end up breaking the setup.

I can imagine other enterprise environments might follow a similar approach.

Best regards,
Sandro Widmann

avatar

Hello Sandro,

I understand your needs. I will keep your request in mind, and we will post back here once we have an update or any questions.

Best regards,

François Dubois

avatar

We would love to see this feature be implemented for our organization as well. We require session recording when connecting to critical infrastructure, but a user could simply bypass that requirement by creating their own session in a user vault. We only want our users to use our approved and managed connections (similar setup to the one OP described).

avatar

Hello,

Thank you for your feedback. I understand your concern and the need for such a feature.

If I understand correctly, your objective is to ensure that access to your critical infrastructure always goes through approved connections where session recording is enabled. Is that correct?

Restricting the entry type in a user vault could partially address this requirement; however, it would not be fully effective, as users could still create connections in other vaults if they have the appropriate permissions. To better understand your use case, are we specifically referring to RDP sessions?

From a security standpoint, the most robust approach to ensure that all connections to your servers originate from a single, controlled entry point is to enforce the use of Devolutions Gateway and configure your firewall to allow connections only from the Gateway.

While users could technically create connections in their user vault using the Devolutions Gateway, it is currently possible to disallow Gateway usage in user vaults, which could address this scenario. Additionally, we could consider enhancing the Virtual Gateway by introducing a rule that enforces mandatory session recording. This could be a valuable improvement to better support your requirements.

Would this approach meet your needs?

Best regards,

François Dubois

avatar
Hello,

Thank you for your feedback. I understand your concern and the need for such a feature.

If I understand correctly, your objective is to ensure that access to your critical infrastructure always goes through approved connections where session recording is enabled. Is that correct?

Restricting the entry type in a user vault could partially address this requirement; however, it would not be fully effective, as users could still create connections in other vaults if they have the appropriate permissions. To better understand your use case, are we specifically referring to RDP sessions?

From a security standpoint, the most robust approach to ensure that all connections to your servers originate from a single, controlled entry point is to enforce the use of Devolutions Gateway and configure your firewall to allow connections only from the Gateway.

While users could technically create connections in their user vault using the Devolutions Gateway, it is currently possible to disallow Gateway usage in user vaults, which could address this scenario. Additionally, we could consider enhancing the Virtual Gateway by introducing a rule that enforces mandatory session recording. This could be a valuable improvement to better support your requirements.

Would this approach meet your needs?

Best regards,


@François Dubois

I personally like the approach of disabling Gateway usage for User vaults (I did not know it was an option) and requiring the use of gateway for remote access to our infrastructure. We currently centrally manage connections and configuration of vaults so enforcing the use of Gateway at the network level should make things pretty airtight!

avatar

Thank you, I'm glad to hear this was helpful.

Please don’t hesitate to reach out if you need further assistance or have any additional questions.

Best regards,

François Dubois