Password Vaults

As an administrator, you use an external application to manage Agent login credentials. This applies to all executable objects that can use Login objects.

This page includes the following:

Overview

In Automic Automation, passwords are typically stored in the database but they can also come from an external application or password vault. In this case, the password is sent directly to the Agent. Automic Automation supports the CA PAM and CyberArk password vaults.

To use a CA PAM or CyberArk password vault with Automic Automation, you have to set it up on an accessible host and install a compatible local Client on the same host in which the Automation Engine runs. Also, Automic Automation has to be added as an application to the password vault and must be configured accordingly, at least with a name.

Note: The local Client is used for the integration with the Automation Engine and contains libraries which must be specified using the libpath parameter in the JWP section of the configuration file (ucsrv.ini). You must restart all Java server processes after setting or changing the libpath parameter in the configuration file (ucsrv.ini).

CyberArk also allows you to use a REST endpoint to retrieve the passwords from the vault instead of using a local Client.

After the application has been set up and integrated into Automic Automation, you have to use the UC_EXTERNAL_VAULTS variable to define how the password vault is identified in your system. Once the setup is complete, the Automation Engine can communicate with the vault.

More information:

CA PAM Password Vault

As an administrator, you setup and configure your CA PAM password vault to be used with your Automic Automation system.

CA PAM Setup

To use the application authentication process that is provided by CA Privileged Access Manager (CA PAM) with Automic Automation, you have to fulfill the following requirements:

  • Install CA PAM on an accessible host.

  • Install CA PAM A2A Client on the host in which the Automation Engine runs.

  • Add Automic Automation as an application to the CA Credential Manager and configure it accordingly.

  • Include the login credentials that are needed as accounts in the CA Credential Manager.

    For more information about the installation and configuration, refer to the official CA PAM documentation.

The A2A Client creates the environment variable CLASSPATH. You need to add this variable (for Windows %CLASSPATH%) to the variable Path in the System variables:

Note: Set the CA PAM SDK library (cspmclient.jar) directory using the libpath parameter in the JWP section of the configuration file (ucsrv.ini):

libpath=C:\capam\cloakware\cspmclient\lib

If you want to configure more than one libpath, separate them using semicolons.

You must restart all Java server processes after setting or changing the libpath parameter in the configuration file (ucsrv.ini).

After CA PAM has been installed and configured to be used with Automic Automation, you have to configure your vault using the UC_VAULT_CAPAM variable. For more information, see UC_VAULT_CAPAM - Password Vault Configuration. Once the setup is complete, the Automation Engine can communicate with the password vault.

CA PAM Accounts

You can add login credentials as target accounts in the CA Credential Manager. The account name must be unique in the target application and must match the user name in the target system. This is also the user name in the Login object that is used to connect to the Agent. The target alias must be unique within the CA Credential Manager.

A CA PAM account containing credentials must be uniquely matched in the CA Credential Manager using the information that is provided in the UC_VAULT_CAPAM variable or in the Login object. An account can only be matched in the CA Credential Manager using the target alias of the account.

If you want to retrieve the credentials of an Agent, you must configure a target alias in the CA Credential Manager and must match it in the Password Vault column.

As a rule, each CA PAM account contains the credentials of exactly one Automic Automation Agent. The exceptions are JMX Agents which have special features and require three accounts for the same Agent. In this case the credentials have to be set in the following format:

  • Account 1: JMX_<alias>_USERPASS

  • Account 2: JMX_<alias>_KEYSTOREPASS

  • Account 3: JMX_<alias>_TRUSTSTOREPASS

Example

If the three accounts for a JMX Agent are JMX_agent1_USERPASS, JMX_agent1_KEYSTOREPASS, JMX_agent1_TRUSTSTOREPASS, then the alias that is configured in the Value 1 column of the UC_VAULT_CAPAM variable must be agent1 for key VLT_ALIAS1.

More information:

CA PAM Caching and Performance

The local Client uses a cache which can supply credentials even if there is a network failure or the vault cannot be accessed. The information that is saved in the cache is encrypted and can only be access following the same authentication criteria that are required to retrieve any other information from the vault. In case the password retrieval fails, the Automation Engine uses the last known credentials cached by the local Client.

If the local Client is not available or if the Automation Engine does not have permission to fetch the password, the user receives a message (last message of the job) with the relevant information and the respective status of the job is set to FAULT_OTHER. For more information, see System Return Codes of Executable Objects.

Note: If a Job fails with FAULT_OTHER and the error message "U00045195 The password request failed with the error message: 'The encryption of the password failed with the error message: Illegal key size or default parameters'." is displayed, you must to copy the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files into the <Java_path>/jre/lib/security folder used by the AWI.

CA PAM Authentication

The application authentication can be done in many different ways, such as:

  • Application name (mandatory)

  • Request server (mandatory) - Authentication is done when installing the local client

  • Execution user ID

  • Execution path

  • File path to application

  • Application hash

In this case, the Application Name and the Request Server are required for authentication. All other parameters are optional and can be used in any combination.

The Automation Engine requests the credentials and the request server verifies that the application details defined in the password vault match the ones of the run-time application. If they do match, the user is granted permission to the vault, the request server retrieves the password and passes it on to the Automation Engine.

CyberArk Password Vault

As an administrator, you setup and configure your CyberArk password vault to be used with your Automic Automation system.

CyberArk Setup

You can set up CyberArk to either use a local Client or a REST endpoint to retrieve the passwords from the vault.

Using a Local Client

To use the application authentication process that is provided by CyberArk with Automic Automation, you have to fulfill the following requirements:

  • Install CyberArk Enterprise Password Vault on an accessible host.

  • Install CyberArk Application Identity Manager (AIM) - Local client (Credential Provider SDK) on the host in which the Automation Engine runs. Make sure the JavaPasswordSDK.jar file is included in the installation.

    Credential Provider compatible versions are all versions that use the same API as 9.6.

  • Use the CLIPasswordSDK provided by AIM to test if the local Client can retrieve passwords from the vault. If the local Client cannot retrieve passwords from the vault, please check your CyberArk Application Identity Manager (AIM) installation.

    • Windows

      CLIPasswordSDK.exe GetPassword /p AppDescs.AppID=AutomationEngine /p Query="Safe=AECredentials3;Folder=Root;Username=NB000829\oab" /o Password

    • UNIX

      clipasswordsdk GetPassword -p AppDescs.AppID=AutomationEngine -p Query="Safe=AECredentials3;Folder=Root;Username=NB000829\oab" -o Password

  • Once your local Client can retrieve passwords from the vault, add Automic Automation to the vault as an application and configure it accordingly.

  • Include the login credentials that are needed as accounts in the vault.

Important! Make sure you set the CyberArk SDK library directory using the libpath parameter in the JWP section of the configuration file (ucsrv.ini); otherwise you cannot use the CyberArk integration. Also, make sure the path points to the location of the JavaPasswordSDK.jar file:

libpath=C:\Program Files (x86)\CyberArk\ApplicationPasswordSdk

You must restart all Java server processes after setting or changing the libpath parameter in the configuration file (ucsrv.ini). After setting or changing an environment variable, you must restart all server processes, as well as the ServiceManager and the Automation Engine.

After CyberArk has been installed and configured to be used with Automic Automation, you have to configure your vault using the UC_VAULT_CYBERARK variable, see UC_VAULT_CYBERARK - Password Vault Configuration. Once the setup is complete, the Automation Engine can communicate with the password vault.

Using a REST Endpoint

CyberArk also allows you to use a REST endpoint to retrieve the passwords from the vault. Optionally, you can use TLS/SSL to secure the connection to the REST endpoint, or use client certificates to authenticate the client - in this case, the Automation Engine - to CyberArk. You can define the REST endpoint you want to reach using the REST parameter of the UC_VAULT_CYBERARK variable, see UC_VAULT_CYBERARK - Password Vault Configuration.

Important!

  • The Common Name (CN) definition in the certificate must match the host that was defined in the REST parameter of the UC_VAULT_CYBERARK variable. Otherwise the authentication fails.

  • Most companies have a certificate policy in place that specifies which types of certificates are used and who in the company is in charge of the certificate installation, distribution and management. As an Automic Automation administrator, you do not need to take over that roll. You only need to make sure you follow the requirements and use the resources of your company to use certificates.

When you use certificates signed by an internal or public Certificate Authority (CA), make sure you follow the policy set for your company.

If you use self-signed certificates, you can store these certificates in the Automation Engine database in the UC_TRUSTEDCERTS Storage object. This object is delivered with Client 0 and allows you to upload the relevant certificate files. For more information, see UC_TRUSTEDCERTS Storage Object.

Note: Self-signed certificates must use the .pem format.

The Automation Engine can authenticate itself to CyberArk using certificates through mutual TLS/SSL. In an on-premises installation, you set up mutual TLS/SSL by defining the following parameters in the [TLS] section of the AE INI file (ucsrv.ini):

  • mutualAuthenticationKeystore= Path and file where the keystore for TLS/SSL mutual authentication is stored

    Default value: ./mutualTlsKeystore.p12

    If this parameter is not set, the system uses the definition of the keystore parameter.

  • mutualAuthenticationKeystorePassword= Password for the keystore file

    Default value: changeit

    If this parameter is not set, the system uses the definition of the keystorePassword parameter.

  • mutualAuthenticationKeyPassword= Password for the key

    Default value: changeit

    If this parameter is not set, the system uses the definition of the keyPassword parameter.

  • mutualAuthenticationKeyAlias= Alias used for the key for mutual authentication

    If this value is not defined or is left empty, the system does not attempt mutual authentication.

To set up CyberArk for an Automic Automation Kubernetes Edition environment, you must create the mutual-tls-cert Kubernetes secret before the installation. The secret contains the private key/cert pair that identifies the Automation Engine to CyberArk. For more information, see Setting Up CyberArk for AAKE.

CyberArk Accounts

A CyberArk account containing credentials must be uniquely matched in the vault using the information that is provided in the UC_VAULT_CYBERARK variable or in the Login object. The following attributes can be used to match an account in the vault:

  • Safe(s): can be specified in the Password Vaultcolumn of the Login object.

  • Object: can be used as the agent name in the Login object

  • AppID: configured in the UC_VAULT_CYBERARK variable

  • UserName: specified in Login object

Note: Agent names are unique in Automic Automation. If the parameter USEOBJECT in the UC_VAULT_CYBERARK variable has been set to Yes, you could use the agent names as object IDs or names for the vault account. Generating names automatically should be disabled.

As a rule, each CyberArk account contains the credentials of exactly one Automic Automation Agent. The exceptions are JMX agents which have special features and require three accounts for the same Agent. In this case the credentials have to be set in the following format:

  • Account 1: JMX_<username>_USERPASS

  • Account 2: JMX_<username>_KEYSTOREPASS

  • Account 3: JMX_<username>_TRUSTSTOREPASS

More information:

CyberArk Caching and Performance

Caching is also available when using CyberArk. In case the password retrieval fails, the Automation Engine uses the last known credentials that are cached by the local client.

By default, the cache is refreshed and synchronized with the vault every 180 seconds. You can modify this interval changing the parameter CacheRefreshInterval in the CyberArk utility appprvmgr for the local client. You can also disable caching in which case the vault is accessed directly to retrieve each credential.

If the local Client is not available, the Automation Engine does not have permission to fetch the password, or the password in the vault has the status Password change in progress, all password requests for this particular password fail. The user receives a message (last message of the job) with the relevant information and the respective status of the job is set to FAULT_OTHER. For more information, see System Return Codes of Executable Objects.

CyberArk Authentication

The Automation Engine uses its unique application ID as defined in the vault to request the credentials. The local Client verifies that the application details (path, hash, OS) defined in the vault match the ones of the run-time application. If they match, the user is granted permission to the vault, the local Client retrieves the password and passes it on to the Automation Engine.