This gist will take on the use cases of using RD managers with PSM or SIA to bypass the need of going to the PVWA every time you want to connect.
In most use cases the PVWA way of working is enough for the end user. We are talking about the average end user using privileged accounts for certain tasks, whether it be general application maintenance, external vendors supporting a product or just general IT workforce doing their daily job.
But in some cases this way of working will be a hinderance and can slow down the workflow of a section of IT workers. The group I'm talking about is server infrastructure managers. This workforce usually have the task of installing and updating servers, and that usually happens in large batches. In these use cases going to the PVWA to launch a session is just tedious and will not be effective.
This is where Remote Desktop managers come in. Here IT personnel can group connections based on servers rather than on an account basis. They can group up connections based on server types, services they provide and generally logically split them how they see fit.
The downside to this is that natively it will mean that this user group will bypass any MFA requirement as they will authenticate directly to the vault. Unless RADIUS is set up with some form of challenge response, it will mean a less secure way of working, and this will not be ideal in an identity driven world.
And in some cases it also means reducing security on the PSM servers themselves, as I explain further down in this gist.
Some RD managers provide an option to sign in to the PVWA with SAML, requiring a form of MFA to retrieve the accounts you have access to. RDM from Devolutions support this, but at quite the cost. Not only do you need enterprise licenses for x number of users (which cost quite alot), but you also have to have the extra CyberArk module to support the SAML integration. The price of this is unknown to me, as I have not contacted their sales team to figure out the actual cost.
RDCMan from Sysinternals have the PAMPlugin from marketplace (also discussed further down), which supports SAML logon to the PVWA to retrieve accounts, but at the cost of reducing the security on the PSMs.
As of version 14 of CyberArk there is implemented SAML logon support for every PSM session started without defining a PSM session ID. I will delve a bit more into detail regarding this in this article.
If you are a Privilege Cloud customer you can leverage SIA, and every tenant delivered since April 2024 have this as a part of the core licensing. If you are not familiar with SIA its a service that allows you to either connect to targets either with a vaulted account, or with Zero Standing Privileges (ZSP), without using the PSM.
Also, if you are a Privilege Cloud customer, you can leverage Identity for authentication and MFA when connecting directly to the PSM, but only when certain criteria is met. More about this further down.
With version 14.2 of pCloud you can also set up a connect to SIA choice on the vaulted accounts in the PVWA. This means you can omit the need for a PSM in your environment. This is for Windows targets only at the moment, and will not work for SSH or database connections.
When using SIA you will be prompted to authenticate with your Privilege Cloud user, either federated or cloud native user. This can require MFA, if your authentication policies are set up properly, meaning you get MFA for every connection made.
To make any RD manager work with CyberArk PSM you need to meet the following requirement:
- Able to disable CredSSP/NLA**
- Start alternate shell**
** Alternatives to this is explained further down
Since the initial release of this gist CyberArk has reworked and released a newer version of the PSMClient.
This client utilizes Cyberark, SAML or RADIUS logon to the PVWA to show the user the available connections. This software will simplify the connection to the PVWA and launching of the connections to the target systems in a nice clear manner. As of now the client does not support SAML pre-authentication, so if you got the PVWA behind load balancers with a direct redirect to an IdP it will fail, as it wont reach the SAML authentication API on the PVWA.
So if you got direct access to the PVWA SAML auth API, you can use the PSMClient to log on and view your available accounts. The client will show tabs as other RD managers do, and you can easily swap between them. RemoteApps, like SSH and others will launch in a separate window. This is not overwritable in any way unless you disable RemoteApp at the connection component level.
You can also group the available accounts by address, target system, platform and alphabetically. PSMClient now also has RDP custom view, where you can create folder and define target systems, and log on to them in the context of an account set as a favorite. This will be more in tune with traditional RD managers. This is prone to change, so check out any release notes to keep updated on your current version and which capabilities it has.
CyberArk released a plugin for RDCMan (downloadable here: RDCMan PAM Plugin) which enables authentication against the PVWA, resulting in loading of your available vaulted credentials. These can be used to connect to the target system (either domain accounts or local accounts).
The implementation guide states that you need to set this GPO setting on either the PSM local GPO or the PSM hardening GPO:
Require use of specific security layer for remote (RDP) connections
Value: RDP
This is along with two other settings, but this one states that you can't use certificate validation when connecting to the PSMs. If the setting is set to Negotiate or SSL it will fail and it will prompt for a password of the PSMConnect user when the session starts. This is also happening even if you set the component parameter "authentication level:i" to 0. The above setting have to be RDP, otherwise it won't work at all.
The RD manager also needs to be able to authenticate the user that has access to the credentials you are accessing. This means that you either have to know your EPV username and password, or if you are LDAP integrated, know your own username and password. Using this setup bypasses MFA, and may not be ideal.
To connect to the PSM with a RD manager you enter the following in the alternate shell line:
psm /u targetuser /a targetsystem /c PSM-RDP
So for a domain user it would look something like this:
Vaulted User info:
- Username: DomainUser
- Address: ad.domain.com
Connectionstring:
psm /u targetuser@address /a targetsystem /c PSM-RDP -> psm /u DomainUser@ad.domain.com /a server1.ad.domain.com /c PSM-RDP
For domain users you must specify the target server with an FQDN or IP address for the target system.
For other connection components you swap out the last part; PSM-RDP for what ever connection component you are connecting through, for instance PSM-SSH.
For local users it is a bit different and would look something like this:
Vaulted User info:
- Username: LocalUser
- Address: 192.168.1.10
Connectionstring:
psm /u targetuser /a targetsystem /c PSM-RDP -> psm /u LocalUser /a 192.168.1.10 /c PSM-SSH
The IP address can be a FQDN, as long as the PSM can resolve it.
If you have an RD manager that does not support alternate shell you can use Start Program, but that has a few limitations:
- The user initiating the session have to have RDP logon rights to the PSM servers
- The environment has to be LDAP integrated as it uses the logon user information to authenticate towards the vault to verify that you have access to the credentials you are trying to use, or the connection must be able to pass a SAML token with the proper claims attached to authenticate towards the vault.
There is a few caveats with this approach, as you must allow non-privileged users RDP access to the PSMs, which might not be desired. It poses a security risk and some organizations might not want to go down that road.
Here is a list of RD Managers that can launch what can only be described as alternate shell (as the individual terminology will vary):
- PSMClient from CyberArk PSMClient
- RD Manager from Devolutions RDM from Devolutions
- MobaXTerm MobaXTerm
- RoyalTS RoyalTS
- mRemoteNG (Nightly build >1.77.3) mRemoteNG Nightly Build (direct download link from GitHub)
And here is a list of RD Managers that can't launch alternate shell, but only Start Program (which requires an interactive logon, resulting in a profile folder, RDP access etc):
- RDCMan from Sysinternals
- This list is currently empty
When you connect directly to the PSM in a Privilege Cloud deployment you will have the option of authenticating to the Privilege Cloud vault. Whether or not you are able to connect to the target system relies on a couple of things:
- The vault user has to be AD integrated, meaning you have to log on with your AD user through the Identity Connector. CyberArk cloud directory user will work, but you will have to enter your credentials instead of auto-populating them. Federated users will NOT work, unless it is an external IdP configured to map against CyberArk Cloud Directory or Active Directory.
- It requires the RD manager to force NLA on the RDP session. RDCMan does this by default, and RDM from Devolutions have the option of enabling this on each connection. I have not tested other RD managers at this stage.
- Add allow RDP connection permissions to the domain users that are authenticating through Identity. This does not create a profile on the PSM
- The end user that is connecting has to have a proper authentication policy and profile defined. The user also has to configure any supported MFA method to be able to trigger the proper logon flow on the PSM. The supported MFA methods are Mobile Authenticator, OTP, Email and code via SMS. Others may be possible. FIDO2 that utilizes an onboard hardware token like biometrics will not work.
- If the target account is a domain account it has to be onboarded to the Windows Domain via LDAP platform and the username must be in the UPN format.
- The client have to be in the same domain as the PSM, otherwise NLA will fail.
The connection string is the as described above with one exception. The target user has to have the username in UPN format AND the address appended to it. It will then look something like this:
Connectionstring:
psm /u targetuser@domain@address /a targetsystem /c PSM-RDP -> psm /u DomainUser@ad.domain.com@ad.domain.com /a server1.ad.domain.com /c PSM-RDP
This method will not work for federated users through Directory services (Azure/Entra, GCP). As mentioned above, using External IdPs with mappings to AD or CyberArk Cloud Directory will work.
As mentioned above, from v14 of CyberArk you have an option of enabling SAML authentication for each connection. This means you can set up a SAML app on your own IdP and authenticate users directly to the vault that way with the use of MFA.
This is useful for environments that are not LDAP integrated, and does not have a RADIUS set up for MFA prompts for LDAP users upon connections. Users in those environments usually dont know their EPV password as the user is provisioned either through an IdM or IGA tool. Authenticating through your IdP also gives the user a uniform way of authenticating to all your services across your organization.
How to configure the SAML setup with Azure is explained here:
Setting up SAML Authentication PSM v14 with Azure
For setting up the RDP file to connect to a target using SAML is quite similar to the alternate shell connections I have described above. My RDP file looks something like this:
full address:s: alternate shell:s:psm /u @
/a /c PSM-RDP enablecredsspsupport:i:0 authentication level:i:1
The authentication level:i:1 isnt required, but I like to have it in there, just to have certificate validation against the PSM. This can't be in the RDP connection file if you are using RDCMan with the PAMPlugin.
When you connect to the PSM this way you will be met with a login screen, with the option to do SAML authentication. The webview window activates and present you with your IdP authentication screen. Once authentication is successful the PSM will verify the username passed back with the vault and retrieve any credential you have requested.
With version 14.2 and above you now also have the option to force SAML authentication when connecting to the PSM this way. This saves you a couple of annoying clicks, and opens the SAML auth prompt automatically. The option to set is under:
Options -> Configurations -> Privileged Session Management -> Server Settings -> Advanced Settings -> SAML Settings -> AuthorizeSAMLAuthOnly
This option set to yes will force SAML authentication when opening PSM sessions through an RDP file or through an RD manager where no username is specified.
The limitations described in the blog means that every connection requires authentication and hence MFA. This is not ideal for end users that opens alot of connections within a short timespan, but its more secure than allowing direct connections with just LDAP authentication which usually is the case with RD managers that isnt licensed in some way. The only exception here is the PSMClient. I don't count RDCMan with the PAMPlugin, mainly because it requires you to reduce the security even further.
As mentioned above, if your Privilege Cloud tenant has SIA licenses enabled you can leverage the SIA connector to either use ZSP or vaulted credentials to connect to target systems, bypassing the need for the PSM.
Setting up the RD manager to use SIA instead of the PSM or using it as a gateway with authentication prior to the PSM is a bit more work than just connecting to the PSM directly.
First you need to create an entry for the target system and which account you want to retrieve.
Name: <Anything thats descriptive to you>
Folder: <Create or select a folder if you want to group connections>
Display: <Your selected preference>
Host: Host configured
Credentials: Username and password
General
Host: <subdomain>.rdp.cyberark.cloud
RDP type: Normal
Username: secureaccess /i <privilege cloud user> /s <subdomain> /d <target account domain> /a <target system FQDN> /u <target account>
RD Gateway
Host: <subdomain>.rdp.cyberark.cloud:443
Logon method: Use a gateway access token
Gateway Access token: secureaccess
checkboxes:
[ ] Open gateway only when unable to ping host
[ ] Bypass RD Gateway server for local addresses
[X] Use same RD Gateway credentials as remote computer
Rest of the settings is up to you to configure, as what devices to connect through, display settings etc.
Link to a RDM template here: RDM SIA Template
As with RDM you need an entry to modify.
In the Server Settings tab:
Server name: <subdomain>.rdp.cyberark.cloud
Display name: <Descriptive displayname>
Parent: <Set your desired parent folder>
In the Logon Credentials tab:
Profile: Custom
User name: secureaccess /i <Cyberark cloud user> /s <subdomain> /d <domain FQDN of the target server> /a <FQDN of the target server>
Password: <leave blank>
Domain: <leave blank>
In the Gateway Settings tab:
[ ] Inherit from parent (can be set as a parent setting)
[X] Use a TS Gateway server
Server name: <subdomain>.rdp.cyberark.cloud:443
[ ] Bypass RD Gateway server for local addresses
Logon method: Ask for password (NTLM)
[X] Share Gateway credentials with remote computer
Profile: Custom
User name: secureaccess
Password: <leave blank>
Domain: <leave blank>
Modify the other settings as desired to match your preferences or needs.
Link to a RDCMan .rdg-file here: RDCMan Template
Anything within brackets < > will have to be modified in the template. Substitute it with the information that matches your environment.
SIA only works for RDP, SSH, database targets and Kubernetes as of now. SIA hosts an RD gateway and a PSM for SSH proxy in the cloud as well as a database proxy, which is used for connections. Recordings is disabled by default, and session isolation is not possible due to the direct RDP nature of SIA.
The advantages of SIA is that it doesnt require alternate shell and is therefore more versatile when it comes to RD managers in general. For RD managers the database option isnt relevant, as you usually use your preferred database management software to connect to these kinds of targets.