Integrating with CyberArk Vault for Single Account
Last updated on 06 September, 2024LogicMonitor 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.
Prerequisites
- 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:
| Name | Type | Default | Details |
| vault.bypass | Boolean | True | If 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.expirationtime | Integer | 60 minutes | Expiration 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.delay | Integer | 15 seconds | The 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 Metadata | Description |
| vault.meta.url | URL of the vault. This URL must contain the folder and application id only. |
| vault.meta.safe | Safe (Applicable only in case of CyberArk). A device can have only a single safe. |
| vault.meta.type | The type of the Vault. Currently, only the “CyberArk” vault integration is supported in the Collector. |
| vault.meta.header | The 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.type | Type of the key store. If the key store type is not specified, the default type for the key store is JKS. |
| vault.meta.keystore.path | Path of the Keystore file. |
| vault.meta.keystore.pass | Password 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 Keys | Description |
| Property suffixed with .lmvault | The 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-Safe | The 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 “vault.meta.safe” 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 /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_Passwordclient.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:
vault.meta.keystore.path=Path_For_Client_Keystore_Folder/client.pfx
vault.meta.keystore.pass=Password_For_Client_KeystoreNote: 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