Renaming Group breaks associated permission

Renaming Group breaks associated permission

avatar

Hello,

this seems to be uncomfortable:








Where does it break the permission? At a connection object or anywhere else?
Is there a way to safely rename groups?

Since User Groups/Roles are widely used within our vaults, renaming could have a big impact?!


Best regards,
Daniel

31c7ad9a-9d48-41bf-a4a5-d552f928ed52.png

13bf23af-7c10-47b0-949f-17d46decda6e.png

All Comments (5)

avatar

Hello dcapilla,

The permissions of the renamed user group will be removed from all the entries (including folders). Assigned vaults will remain as is.

With database data source (SQL for example), you will have this behavior when renaming the user groups, so yes, it would have a major impact.

With Devolutions Server or Hub Business, if you used AD (Devolutions Server only) or AAD groups, they can be renamed in AD/AAD and since it uses the SID, the change will be replicated with no ill effect.

Best regards,

Richard Boisvert

avatar

Hello Richard,

what I can't understand is, that the group-object names are not just aliases for the "primary keys".
Even, if best planed, there could be mistakes or changes after time, since the configuration/naming was done.

So just for my understanding, why is renaming a problem, when using a SQL-DB (or other data source) for RDM?
All applications we work with so far, using SQL-DBs, do not have this behaviour regarding the renaming of objects (users, groups, etc.).

Is this an issues, you could improve in a future release?


Best regards,
Daniel

avatar

Hello Daniel,

Unfortunately, our original architecture wasn't built the way you described, and I take responsibility for not anticipating the evolution of RDM. Migrating the structure in SQL Server is challenging due to the way we store security in the entry. However, this issue has been resolved in DVLS, which has a much-improved security architecture. We now highly recommend our users to choose or migrate to DVLS, and we're less confident in recommending SQL Server as a data source compared to five years ago. It's not about the money; if migration is a barrier, feel free to contact me personally. The concern lies in the client-server architecture where the database is exposed, and as we receive more customer security audits, the recommended solution is to upgrade to DVLS, which provides a middle-tier in front of your data.

By the way, the latest version of DVLS includes SQL Server migration tools.

Regards

David Hervieux

avatar

Hello David,

this is a pity. So if you say "migrate to DVLS", it means to subscribe also to DVLS *on top*, right?


Regards,
Daniel

avatar

Yes and no, like I mentioned this decision is to improve the security model and to enable many features we can't just do in a client-server architecture. We will give a huge discount (near the cost of DVLS) for long time users since our goal is not to increase our sales with this move. You can contact me directly when you are ready.

Regards

David Hervieux