Online Help > Getting Started

Managing Credentials

Description

 

Depending on your organization's security policies, there are multiple ways of handling credentials. We can manage a wide range of scenarios, the most popular being listed below.  What is critical to understand is that these are the credentials used to connect to remote hosts, not the ones you used to launch Remote Desktop Manager.

 

Most of these choices do not exist in the Free edition of Remote Desktop Manager as they depend on features offered by an Advanced Data source.

 

A few key points that the admin of the solution must be aware of:

 

Password visibility

You can store passwords in a Credential (Username/password entry, which (by default) makes the password USABLE, but not VISIBLE, by the end user. You could also use a Information - Account entry, which makes the password completely accessible. You should always consider carefully which type you are using based on your security needs. Both types can be referenced by our sessions/folders when choosing Credential Repository for the Credentials property.

Credentials set on folders

Our folders can have credentials defined. This is useful because in the great majority of cases, one reuses the same credentials for a whole branch of the network infrastructure.  To make use of credentials defined in a folder, the sessions below must be adjusted to use Inherited Credentials.

Entry location

When storing entries in the tree view, users with the View permissions on that entry (or folder by inheritance) will be able to make use of them. This is how you would share credentials with other members of your team. A Private Vault exists for users to store private information that should be seen by no one else. To be able to bridge the gap between the Private and Public area of the system, one must make use of the User Specific Settings feature that is described below.

User Specific Settings

User Specific Settings are overrides for CERTAIN settings of your entries, most notably the Credentials. When applying such an override, one can choose the type in the credentials directly in the override, or one can choose to instead link to credentials stored in one's Private Vault.

 

Here are the most common scenarios and how to address them.  In the great majority of cases, we prefer to have sessions use inherited credentials, meaning it climbs up the tree until it has access to a set of credentials, be it defined, linked, or overridden in an entry.

 

SCENARIO

STRATEGY

One credential is used by all of the staff, be it for the whole system, or for a branch in your tree view (Customer, Department, etc).

Set the credentials on the Root settings. All children use Inherited Credentials.

Each user has its own credential for many different branches (often corresponds to customers/departments, etc)

Make use of the User Specific Settings on each branch. All children use Inherited Credentials.

Each user has its own credential managed by an administrator.

This solution involves a little more work.  The admin must create a folder for each user, then grant permissions ONLY to that user. The user will then use User Specific Settings to specify that the credentials stored in that folder is used to override what is defined in the entries.

Each team uses the same credential.

Much like directly above, but all the members of the team have access to the folder.  All of them must make use of User Specific Settings.

Each user uses their domain account.

Have the sessions configured to use My personal credentials, each user will be prompted to define them once per workstation that they use.