Integrating with CyberArk Vault for Single Account

Last updated on 26 April, 2024

LogicMonitor stores sensitive information including credentials, secrets, etc for hosts, devices, services. The LogicMonitor Collector provides the integration with CyberArk as a vault solution. For more information, see CyberArk documentation. 

To integrate the CyberArk Vault with LogicMonitor Collector, see Integrating with Credential Vault.


  • The CyberArk Vault Integration requires EA Collector versions 29.108 or higher. Note that support for the vault integrations are not yet available in GD Collector versions.

CyberArk Application Authentication Methods

The CyberArk Credential Provider provides multiple methods to authenticate applications. For more information, see CyberArk documentation on Application authentication methods and Add applications.

LogicMonitor Collector and CyberArk integration support the following methods for the application authentication:

1. Allowed Machines
2. Path
3. Hash
4. Client Certificates

Note: We recommend configuring Dual Accounts in CyberArk for widely-used, frequently rotated credentials to avoid account lockouts during rotation.

Authentication to Privileged Access Security (PAS) Solution

The CyberArk AIMWebService application is deployed on the IIS Server. LogicMonitor Collector and CyberArk integration uses Basic Authentication to the IIS Server.

You can log on to the Vault by using the password that is provided to you. After logging into the Vault, we recommend that you change your password.

CyberArk Collector Agent Configuration Settings

The following  table contains the collector agent configuration related to the vault:

vault.bypassBooleanTrueIf the value is set as true, the vault API will not be called. If the value is set as false, the vault API would be called.
vault.credentials.cache.expirationtimeInteger60 minutesExpiration timeout (in minutes) for credentials in vault cache. After this time, the credentials in the vault cache expires and would have to be re-fetched from the Vault. 
vault.credentials.refresh.delayInteger15 secondsThe amount of time delay (in seconds) after credentials cache expiration time. Refresh the task after the cache expiration time.Note: You may customize the amount of time delay while installing the collector.
For more information, see agent.conf Collector Settings.

Vault Properties

Vault properties, such as Vault Metadata and Vault Keys for the collector, can be configured at the device or device group level.

Note: CyberArk does not allow special characters, such as \ / : * ? ” < > , to be used in Safe names and object names.

Vault Metadata

The following table lists the Vault Metadata properties.

Vault MetadataDescription
vault.meta.urlURL of the vault. This URL must contain the folder and application id only. 
vault.meta.safeSafe (Applicable only in case of CyberArk). A device can have only a single safe. 
vault.meta.typeThe type of the Vault. Currently, only the “CyberArk” vault integration is supported in the Collector. 
vault.meta.headerThe headers required for HTTP Get Request. The value for this custom property would be the header separated with “&“ the header key value would be separated with “=” as shown in the below example:vault.meta.header – Content-Type=application/json&Accept-Encoding=gzip, deflate, br
vault.meta.keystore.typeType of the key store. If the key store type is not specified, the default type for the key store is JKS.
vault.meta.keystore.pathPath of the Keystore file.
vault.meta.keystore.passPassword for the Keystore.

Vault Keys

Vault keys need to be specified at the device level with suffix .lmvault. For example, ssh.user information should have the key specified as ssh.user.lmvault.

Vault KeysDescription
Property suffixed with .lmvaultThe custom property for which value must be retrieved from the Vault and must be specified at the device level by adding suffix .lmvault. The value of such property would be the path of the key in the Vault.For example: ssh.user.lmvault = ssh\ssh.userFor ssh.user.lmvault, the property should be retrieved from the Vault. The value of this property “ssh\ssh.user” represents the path in the Vault where the credential is stored.
Property suffixed with .lmvault : Multi-SafeThe multi-Safe approach allows fetching the values for lmvault properties from different safes within the Vault. The LM vault property value should be specified in the format safe:path.For example, the property referring to the safe sshcreds and object path as ssh\ssh.user can be specified as: ssh.user.lmvault = sshcreds:ssh\ssh.userThe Safe specified at the property level would override the value specified at the device level through the “” property.

Collector and CyberArk Vault Integration

1. Multi-Safe support: Specify the multiple safes under a device to retrieve the credentials from Multiple Safe.

2. Multi-Vault support: You can use multiple vaults for the devices under the collector. Each of the devices can point to a single Vault.

3. You can call Vault API over HTTP or HTTPS. However, if you are calling the Vault APIs over HTTPS, you must configure the RootCA cert. For more information, see RootCA cert.

4. You must complete the CyberArk Authentication. For more information, see  CyberArk Application Authentication Methods section

Note: Device-specific cache is implemented at the collector to avoid frequent requests to the Vault API.

Configuring CyberArk Certificates

You must configure the following CyberArk files at the requesting application side:

  • RootCA cert
  • client.pfx file
  • client.cert and client.pem files

RootCA cert

You must enable the Require SSL checkbox for including the RootCA cert file in the trust store of the requesting application’s server. 

To import RootCA cert for the collector, complete the following steps:

  • Windows: RootCA cert must be imported in the collector’s trust store in JRE within the Collector installation folder. By this, the CyberArk endpoint will be considered a trusted source.
  • Collector’s installation directory. The default file path is:
  • Linux Collectors: /usr/local/logicmonitor/agent/conf
  • Windows Collectors: C:\Program Files (x86)\LogicMonitor\Agent\conf\agent.conf

To import RootCA certificate in the collector’s jre default trust store, use the command:

keytool -importcert -file Path_For_Root_CA_Folder/RootCA.crt -alias CyberArkRootCA -keystore /usr/local/logicmonitor/agent/jre/lib/security/cacert -storepass Store_Password

client.pfx file

CyberArk provides client.pfx file which is a pkcs12 file containing the client certificate and client key. The client certificate and client key must be present in the HTTP request to authenticate the application request to IIS. As the client.pfx is a key store containing the client certificate and client key, this file can be directly used to authenticate the collector’s request with Vault Service deployed on IIS.

To use the client.pfx file, set the below properties at the device/device group level at the Santaba:


Note: The default keystore password for client.px store is CyberArk 1. We recommend that you change this password.

client.cert and client.pem files

Though CyberArk provides the client.pfx key store containing the client certificate and client key, it still provides the client.cert and client.pem files. These files can be used to create the custom key store. Such a custom key store can be used to authenticate the applications/collector’s request to the IIS server on which Vault Credential Service is deployed.

To create the key store using client.cert and client.pem files, use the below command.

openssl pcks12 -export -in Client_Cert_Folder/client.crt -inkey Client_Key_Folder/client.pem -out myclient.pfx -passout pass:Password_For_Generated_Keystore
In This Article