During the last few months, you may have noticed a heightened level of collaboration between Devolutions and CyberArk Indeed, two of our three entry types have been refreshed in version 2020.2 to better use their improved APIs. Our third type is already available in Remote Desktop Manager 2020.3 beta, this completes the current round of improvements and essentially allows organizations to go password-less for their day-to-day workflows.
The only requirement is that you operate CyberArk's Application Access Manager (AAM) as part of your organization’s CyberArk deployment. This module allows for Private Key (PK) authentication, which means that the whole Identification/Authentication phase is managed by your IT Department, rendering passwords completely unnecessary.
Also, let’s start with a caveat that the password-less part is in regards to CyberArk, you still have to authenticate to Remote Desktop Manager, whatever datasource you are using.
A diagram is necessary to properly illustrate the solution. 
The user is authenticated to Remote Desktop Manager with a Least Privilege Account, this gives them a view into the Remote Desktop Manager content as per the permissions set in our User Groups Based Access Control.
When their Privileged Account is required to launch a supported technology, Remote Desktop Manager will obtain the appropriate Private Key from the workstation, it must be held in the certificate store for the user.
The PK is used to authenticate against the CyberArk vault. It’s configured as an Application object that is essentially a user proxy used to query the vault.
Remote Desktop Manager obtains the details of a Privileged Account, what is key is that the user does not know the password for their own privileged account.
Remote Desktop Manager uses the Privileged Account and launches either: a PSM Connection; connects to the PVWA; or even launches a session supported by Remote Desktop Manager, all the while still hiding the password from the user.
First, you must issue PKs for each of your users and deploy them to their workstations. The source of truth for these matters is surely the CyberArk documentation, but we have included basic instructions in our integration guide. As for the Remote Desktop Manager side, again we support different methods of managing the PK:
PK information stored an entry which exists in the user vault. This is surely the most simple as you have a one-to-one relationship between users/keys/accounts, but it has to be done by the users themselves.
PK information stored in My accounts settings: This method allows the administrators to create the AAM entries within Remote Desktop Manager, while each user sets their own PK details in their own personal settings. Since the account lookup uses keywords specified in the AAM entry, it means that you have a few options still:
Handled in CyberArk: for each user there need to exist a single Privileged Account, accessible from the same keywords. The burden is on the administrator to isolate those in various safes and to ensure that everyone’s account has the same keywords.
Handled in Remote Desktop Manager: administrators need to create a unique AAM entry per user with the keywords to find their Privileged Account. Our User Groups Base Access Control must be used to ensure that users can view and use only appropriate entries.
As always with Remote Desktop Manager, you can mix and match approaches depending on your own requirements.
An application name other than AIMWebService must be specified in the application name field.
A discussion on the PSM is surely too broad to fit in this topic, so I will again refer to CyberArk’s documentation. As for Remote Desktop Manager, in your PSM-Server entry, use one of our mechanism to have the connection use the AAM entry configured in the previous step.
If you have chosen AAM option 1 above, you must use the User Specific Settings in Remote Desktop Manager to create the link between the PSM-Server entry and the AAM Entry that is stored in the user vault.
If you have rather selected options 2a or 2b, I believe that the best option is to set the PSM-Server entry to use Credential Repository, paired with prompt on connection This makes the experience better for new users, and experienced users will know how to switch to User Specific Settings to make their choice more permanent.
When you stay within the confines of your CyberArk ecosystem, you typically do not need to use this type, but it was decided to still offer you the capability. This has just recently been modified and therefore is only in the 2020.3 release, which is in the beta cycle at this time.
That being said, it allows your organization to give access to grab certain passwords, whenever the PSM or using Remote Desktop Manager’s account brokering is not an option, all the while still allowing only access from a Privileged Account that the user does not control.
For the full details, here is the official documentation for each of our integration, as well as a few links to our own documentation on features mentioned in this post.
Integration guides (download link from our CDN)
Remote Desktop Manager Help
As always, please contact our customer support team at [email protected] if you’d like a walk-through or if you need to clarification on certain aspects.
Give us Feedback