Password Vaults

As an administrator, you use an external application to manage passwords and agent login credentials.

This page includes the following:

Overview

In Automic Workload 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.

To use a password vault with Automic Workload 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 Workload 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). For more information, see Automation Engine. You must restart all Java server processes after setting or changing the libpath parameter in the configuration file (ucsrv.ini).

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

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.

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 Setup

To use the application authentication process that is provided by CyberArk with Automic Workload 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 Workload Automation to the vault as an application and configure it accordingly.
Include the login credentials that are needed as accounts in the vault.

Note: Set the CyberArk SDK library directory using the libpath parameter in the JWP section of the configuration file (ucsrv.ini). For more information, see Automation Engine. 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 CyberArk has been installed and configured to be used with Automic Workload Automation, you have to configure your vault using the variable UC_EX_CYBERARK - Password Vault Configuration. Once the setup is complete, the Automation Engine can communicate with the password vault.

CyberArk Accounts

A CyberArk account containing credentials must be uniquely matched in the vault using the information that is provided in the variable UC_EX_CYBERARK - Password Vault Configuration or in the Login (LOGIN) object. The following attributes can be used to match an account in the vault:

Safe(s): can be specified in the Vault / Safe column of the Login object.
Object: can be used as the agent name in the Login object
AppID: configured in UC_EX_CYBERARK - Password Vault Configuration
UserName: specified in Login object

Note: Agent names are unique in Automic Workload Automation. If the parameter USEOBJECT in UC_EX_CYBERARK 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 Workload Automation agent. The exceptions are JMX agents which have special features and require three accounts for the same agent. For more information, see Login (LOGIN). 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

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.