Online Help > Support/Resources > Best Practices




Remote Desktop Manager's security allows you to create a granular protection system that is quite flexible, but flexibility comes at a price and sometimes making the wrong choices could increase the time involved in managing your system.


What follows are recommendations from our experience with the system as well as from users that have shared their ideas with us.




Your staff is organized in "teams", but to use a generic concept we'll use Tiers in our examples. Small organizations often have two tiers (teams), but larger ones may have four.


Tier 1 is often the top level system administrators. They have full control of everything.

Tier 2 is for the staff that can see everything, but can edit only a subset of entries. They usually correspond to Service Desks, the senior staff, etc

Tier 3 is for the staff that has limited visibility over the infrastructure. They have mostly read only rights, but may be able to edit sessions for certain groups. Help desks typically fall in that category, as well a junior staff members.

Tier 4 is for read only access. Often for external consultants that come in for a mandate. They cannot see any passwords or entry details.




Do not replicate your AD groups.


Remote Desktop Manager groups are to separate entries (sessions, credentials, etc), not users. Tier 3 personnel may have access to Group A in a read only mode, Group B in read/write mode and not even see Group C, but Tier 2 personnel may have the right to edit everything. You will grant users the appropriate rights for each security group.


Create a folder structure much like your organization is managing its operations


Its best to separate by area of concerns. Think of your sessions and credentials and separate them by your wish to make them A - visible and B - editable to each of your tiers. Each "intersection" of privilege by a subset of your team means another root level folder.




Once you have separated sessions into groups, create a root level folder for each group and give it a meaningful name. After that assign a security group to the root level folder.


That sounds too complicated? A short version for a Managed Service Company would be to have a Group for the Customers and one for their own infrastructure (lets name it using the name of your company, I'll use Internal in the documentation). Another version for a large corporation could have Production, Staging, Testing.




After that, open the user to assign his rights for the group as described in Permissions.


User Management

User Management


Assign security groups to high level folders


If you need to assign security groups to a deep folder, or to a specific entry, then you are creating an exception. It may end up consuming a disproportionate amount of time to manage these exceptions. You should look at the possibility of creating a new folder to make things clear for everyone in your organization.


Use the shortcut feature to give different permissions for an entry.


As can be seen in Creating Shortcuts, an entry can appear under more then one folder. This is our recommended practice whenever you need to assign multiple permission sets to the same entry and you run into issues because its doesn't fit your security scheme.