Changes to security architecture

Hi @sjames
I’m truly sorry for the inconvenience this change has caused.
Our goal behind this update was to help customers better manage their permissions.
We often noticed cases where users granted permissions within a vault but forgot to give access to the vault itself, which caused a lot of confusion.

If I understand correctly, please let me know if I’m mistaken, you have one group controlling access to the vault and other groups used to manage access to specific folders or entries.
These secondary groups gain access to the vault through nested groups.
Is that correct?

In this case, we hadn’t anticipated this particular setup.
To help you maintain your current structure, I’d suggest that we allow permissions to be assigned to user groups at all times, even if they don’t have explicit access to the vault.
Would that work for you?

Additionally, we recently introduced a feature that allows linking a credential from another vault (via the Linked (external vault) option).
This might help you reduce the number of credentials you need to manage per vault.

Thank you for the feedback

Thanks Marc,

If I understand correctly, you have one group controlling access to the vault and other groups used to manage access to specific folders or entries.
These secondary groups gain access to the vault through nested groups.

We have specific security groups that control access to the vault. RDMS_Vault1, RDMS_Vault2. Then we have security groups for controlling access to credentials, password and entries within a vault. Let’s call those groups RDMS_Cred1, RDMS_Cred2

We use RDMS_Cred1 and RDMS_Cred2 in both vaults. For this example, let’s assume that all passwords in Vault1 and Vault2 are locked down to group Cred1 and all credentials are locked down to Cred2

Let’s say User1 has access to both Cred# groups, but they are only a member of RDMS_Vault1. Because they are NOT a member of RDMS_Vault2, they never see entries, passwords, credentials in that vault because they can never get to that Vault in the first place.

I’d suggest that we allow permissions to be assigned to user groups at all times, even if they don’t have explicit access to the vault.

This is the way it was before the change, which would work for us. Maybe you leave it as per screenshot (warning message ‘No vault access’) so it’s a cue/help for customers, but still allow the group to be assigned.

we recently introduced a feature that allows linking a credential from another vault (via the Linked (external vault) option).
This might help you reduce the number of credentials you need to manage per vault.

Yes this is a terrific feature, moving all credentials to a single central vault and linking to that. For us this is a massive change to rearchitect though given the amount of vaults and entries we have - definitely on the to-do list one day :)

In this case, we hadn’t anticipated this particular setup.

It is impossible for Devolutions to know how every system is setup. Maybe there needs to be a forum setup, or a group of Devolutions customers, where changes like this are floated and feedback sought. Changes to the way security works can have a massive impact on the system, as it is for us now. We effectively cannot add/edit/change/modify any permissions at all as it stands.

Hi, @sjames
I completely understand, and I apologize for the inconvenience.
We’re currently implementing a solution for both RDM and DVLS.

I’ll keep you updated on when and in which version the fix will be available.
Thank you for your understanding.

Much appreciated

Hello @sjames ,

We released DVLS 2025.3.5 (https://devolutions.net/server/download/) containing the fix.

Let us know if it's now working as it should.

Thanks!

Best regards,

Hi @Alexandre Bélisle - unfortunately the problem still exists

Hello @sjames,
Thanks for your feedback.

Can you confirm you also updated RDM? This should work starting from 2025.3.18.

Furthermore, from the web:

Do you have a different behavior?

Thanks for letting us know.

Best regards,