StrongDM bills itself as a Zero Trust PAM solution. It offers a pretty slick way to access resources through a Desktop client as well as a CLI. With either installed, you can easily connect to resources using native tooling. It is a nice alternative to the Privileged Session Manager (PSM).
The credentials for accessing resources can be stored in StrongDM's Strong Vault (a "simple" secret store) or StrongDM can integrate with various third party stores such as CyberArk — now Idira — (self-hosted PAM and Conjur), AWS Secrets Manager, Azure Key Vault, and a few more.
This is a quick article on integrating CyberArk self-hosted PAM as a secret store in StrongDM.
Reading through the documentation
StrongDM provides documentation for integrating CyberArk self-hosted PAM as a secret store but it is largely incomplete, and in one spot even incorrect, but depending on your familiarity with CyberArk, you can read between the lines as to what you need to do.
The first is creating the necessary users in CyberArk and configuring the gateways and relays to use them.
First, any gateway(s) and relay(s) that you intend to use to access resources with via CyberArk PAM must be configured to authenticate with CyberArk. Due to the manner in which CyberArk identifies users and manages seats, each of those gateways and relays must be set up in CyberArk as a user with its own credentials. Once this is done, those gateways and relays are capable of authenticating to CyberArk in order to fetch the required credentials to connect a user to a protected resource.
On the gateway or relay, set the environment variables PAM_USERNAME and PAM_PASSWORD with the user’s corresponding credentials as the value. You can also set PAM_TLS_SKIP_VERIFY=true to skip certificate verification if the CyberArk instance doesn’t have a valid certificate.
Without explicitly saying it, we can safely assume the integration uses the Password Vault Web Access (PVWA) REST API.
The justification for needing a CyberArk user per gateway or relay isn't clear to me but this requirement could also be in part due to not setting the concurrentSession parameter to True when calling the Logon endpoint.
The documentation doesn't mention how the CyberArk user authenticates. What is also missing are the needed safe memberships the users must have but they can already be assumed based on the nature of the integration.
Afterwards we set up the Secret Store in StrongDM.
In the Admin UI, go to Network > Secret Stores.
Click Add secret store.
Give the secret store a name that is recognizable within your organization, such as “CyberArk PAM.”
Choose CyberArk PAM as the secret store type.
For the application URL, enter the IP address of the Windows server that hosts your Central Credential Provider
Straight forward however step 5 looks to be incorrect. As we need to create CyberArk users for each gateway and relay and set the PAM_USERNAME and PAM_PASSWORD environmental variables, it must mean the PVWA and not the Central Credential Provider. Note: I submitted a case to StrongDM support about CCP vs PVWA and they've already replied they are passing it on to the Docs team.
There is no option to choose how the gateways and relays should authenticate with their CyberArk user so it likely only works with the users doing Vault authentication.
The last part is configuring a StrongDM resource to use an account in CyberArk. The example below uses a database.
From the Admin UI, go to Infrastructure > Datasources.
Click Add datasource.
Enter the properties for your database resource.
From the Secret Store dropdown menu, select the CyberArk PAM option.
In the Username (path) field, add the path to retrieve the username, in the format <ACCOUNT_ID>?key=username. Use the CyberArk account ID of your resource, followed by ?key=username.
In the Private Key (path) field, add the path to retrieve the password, in the format <ACCOUNT_ID>?key=password. Use the CyberArk account ID of your resource, followed by ?key=password.
When all required fields are complete, click Create.
The need to use an account ID cements the fact that the integration is using the PVWA REST API. An account ID is a construct only used in the PVWA.
Integrating CyberArk self-hosted PAM
The documentation is enough to get us started and we can fill in the gaps along the way.
As my lab environment only has a single gateway, I create a single CyberArk Vault user named strongdm. Despite the documentation saying nothing about safe memberships, we know the user needs something and List accounts together with Retrieve accounts on the safes containing accounts we want to use with StrongDM resources makes the most sense to start with.
I created a gateway on an existing Linux server in my lab and need to set the PAM_USERNAME and PAM_PASSWORD environmental variables.
PAM_TLS_SKIP_VERIFY is set to true as my PVWA's certificate's issuer is not trusted by my Linux server.
Adding CyberArk as a Secret Store is effortless. We just need to keep in mind that, despite the instructions, we provide the URL of the PVWA and not a Central Credential Provider instance. We also do not need to add the /PasswordVault/ path.
Once the secret store is created, it is marked as healthy as it is reachable by at least one gateway.
If we needed any more proof, we can check the IIS logs. 192.168.0.4 is the Linux server with the StrongDM gateway installed.
We can follow the steps for configuring a StrongDM resource to use an account stored in CyberArk self-hosted PAM quite literally. We just need the ID of the account we want to use.
A browser's developer tools is the quickest way to find an account's ID but if we needed to automate the adding of StrongDM resources using CyberArk accounts, the Get Accounts endpoint would be more appropriate.
With the account ID in hand, adding the resource looks like the following:
After resource creation, it is marked as healthy for our Linux gateway.
In activities for the account, we see the retrieval by the strongdm user with the reason "StrongDM Connection".
And for the ultimate test: a screenshot of the recording connecting through StrongDM.
Even with the documentation for the integration not being complete, it was still pretty quick and easy.
Closing thoughts
For what it is, StrongDM's CyberArk self-hosted PAM integration works nicely. A few thoughts:
Being that it works with the PVWA REST API, it doesn't require any Central Credential Provider or Credential Provider licenses, which -- together with removing the need for any PSMs and their associated RDS CAL costs -- can be a nice cost savings.
Having to use the ID of an account can make the initial creation of a resource a bit of a pain but with how fast connecting to a resource with StrongDM is, even when StrongDM needs to retrieve the password from the PVWA, it makes up for it.
If the accounts you intend to use with StrongDM resources will also be used by users for password retrieval or PSM sessions in CyberArk, you need to be mindful of the platforms having exclusive usage active as StrongDM will not check-in an account after a StrongDM connection closes.
Don't forget to provide Access Safe without confirmation in addition to List accounts and Retrieve accounts to StrongDM's CyberArk users when accounts have dual control enforced.
Central Credential Provider integration would be a nice option. StrongDM does not seem to retrieve the password for an account for each connection so you could run the CP without cache in order to not hit the 10,000 mark. To avoid the CP having access to more than 50,000 accounts, a gateway or relay could use a CyberArk Application that has access to a certain scope of accounts.
Expanding support to CyberArk's Privilege Cloud would be a big plus as together with StrongDM it could greatly reduce the amount of infrastructure you need to manage for a PAM solution.
Let me know your experience with integrating CyberArk self-hosted PAM and StrongDM.
