CyberArk PSM connection workflow clarification
Hello,
I would like to confirm whether my understanding of the CyberArk PSM workflow in RDM is correct, and to raise a feature request based on a limitation we are hitting with multiple CyberArk environments.
My current understanding of the setup
1. Create a CyberArk Dashboard entry.
2. Create a CyberArk PSM Server entry (defining the PSM host and the authentication used to connect to the PSM server itself).
3. Create a CyberArk PSM Connection entry that references the PSM Server entry and specifies the privileged account and connection component.
My current understanding of how to launch a connection
1. Log in to the CyberArk Dashboard.
2. Open a safe that contains the account/entry I want to reach.
3. Right-click the PSM Connection entry and choose "Connect Using" and the previously defined CyberArk PSM Server.
Questions
1. Is this the correct/intended way to open connections through a PSM proxy using the PSM Server + PSM Connection entry types?
2. If I am not logged in to the CyberArk Dashboard, the "Connect Using" option does not appear on the PSM Connection entry. Is this intended, even though the PSM Server entry itself can hold a username/password (Custom mode)? If so, what is the intended purpose of those credentials stored on the PSM Server entry and when are they actually used versus the Dashboard session?
---
Fortunately, we can work around this with a plain RDP entry> connecting directly to the PSM server and specifying the program to run on connection as psm /u <user>@<address> /a <address> /c PSM-RDP. However, this wouldn't scale if we had multiple SAML-authenticated CyberArk environments that need to be defined through the Dashboard entry.
Thanks!
Kind regards,
Daniil
All Comments (3)
Hello Daniil,
Thank you for reaching out.
My name is William, and I’ll be assisting you with this.
The CyberArk PSM Server and CyberArk PSM Connection entries are no longer the recommended approach for launching sessions through CyberArk PSM.
The recommended approach is to use the CyberArk Dashboard with standard RDP entries.
In this workflow, you would:
- Open and authenticate to the CyberArk Dashboard.
- Navigate to the desired safe/account.
- Select the desired account in the Dashboard.
- Launch the standard RDP entry.
Please also ensure that the Connect using dashboard on double-click option is enabled in the RDP entry properties under the Advanced tab. When you double-click the RDP entry, RDM should prompt you to select the connection component to use. You can then select the appropriate PSM component, and the session should launch through CyberArk PSM.
Alternatively, you can use a CyberArk PVWA credential entry instead of the Dashboard. With this entry type, you can set the Resolving mode to PSM Connection and link the credential entry to a standard RDP entry. When launching the RDP entry, RDM will use the account configured in the CyberArk PVWA credential entry and route the session through PSM if the resolving mode is configured accordingly.
For more information, you can refer to the following documentation pages:
- https://docs.devolutions.net/rdm/kb/how-to-articles/cyberark-pvwa/
- https://docs.devolutions.net/rdm/kb/how-to-articles/cyberark-dashboard-configuration/
Regarding the Connect Using option not being available when you are not authenticated to the CyberArk Dashboard, this is expected. RDM only offers this option when a CyberArk Dashboard is opened and authenticated successfully.
Best regards,
Hello William,
Thank you, this all makes sense. We'll move to the Dashboard + standard RDP entry approach. After testing, the PVWA credential entries seem to cover the per-server account workflow, I'll add to this conversation if I find anything else.
One thing remains. Using the Dashboard or a PVWA credential entry for the RDP launch works fine, but the credential source on the PVWA credential entry itself is an issue: there doesn't appear to be an option to pull credentials from the User Vault.
For context, our setup is several separate CyberArk environments, each with its own predefined PVWA connection, and multiple users sharing the data vault. Against that, none of the available credential sources fit:
- Custom (hardcoded into the entry): not suitable, since the vaults are shared.
- CyberArk AAM: not usable, we don't use AAM in any of our environments.
- My Account Settings (PVWA): not workable either, as it only holds a single account and can't distinguish between Dashboards. For example test and prod environments could use different accounts, so one per-user PVWA account can't cover both.
What we'd want is the ability to extend the ability to select credentials from the User Vault on the PVWA credential entry so it's more on pair with a selection in plain RDP (Find by name, Linked and so on). Is this already planned on your side, or should I raise a feature request for it? It would be nice to have these options added to all CyberArk related connection entries.
Thanks again,
Daniil
Hello Daniil,
Thank you for the detailed follow-up — this is a good edge case to document.
The cleanest solution, if your CyberArk environments support it, is to set the Authentication on the PVWA credential entry to SAML. With SAML, there are no stored credentials at all — each user authenticates through their identity provider session at launch time. One shared PVWA entry per environment, no per-user duplication required.
If SAML isn't available in all your environments, the workaround is to have each user create their own CyberArk PVWA credential entry in their User Vault — one per CyberArk environment — and then link the shared RDP entries to those User Vault PVWA entries using Find by Name. The naming convention will need to be consistent across users for the lookup to work reliably. It's more maintenance overhead, but it gives each user per-environment credentials without putting them in a shared entry.
As a side note, we don't have plans to add User Vault credential sources directly to the PVWA entry's authentication in the way you're describing. If this is a workflow you'd like to see supported, I'd encourage you to submit a feature request through the forum or via our feedback portal — that's the best way to get it tracked.
Best regards,
