Read and Review Automation Anywhere Documentation

Automation 360

Close Contents


Open Contents

Using external key vaults

  • Updated: 2022/05/03
    • Automation 360 v.x
    • Explore
    • RPA Workspace

Using external key vaults

Use the external key vault technology by integrating the Automation 360 platform with third-party key vaults such as AWS Secrets Manager, Azure Key Vault, and CyberArk.

Third-party key vault integration

Automation 360 uses credentials to support business services, such as database connections, Active Directory Integration, and Simple Mail Transport Protocol (SMTP) operations. These services can be configured to retrieve the necessary authentication from the integrated external key vault. Only encrypted credentials can be passed from the Control Room to the Database server and are stored in the external vault.

Additionally, auto-login credentials and credentials used by RPA (bots) can be configured for retrieval from the integrated key vault.

Before proceeding, ensure that you have the following information:
  • Any necessary database and user credentials.
  • Any necessary credential requirements for the external key vault, such as secret keys and application IDs. See the specific requirements for your external key vault on the External Key Vault integration configure page.

Retrieving Bootstrap/System Credentials

Bootstrap credentials are those credentials used by the Control Room to access supporting services such as database, service account, Active Directory, and SMTP. Database, service account, and Active Directory credentials that are used by the Control Room are configured for retrieval either during initial installation or post installation via the key vault utility. SMTP credentials are configured through the UI under Administration > Settings > Email Settings. Configure bootstrap credential retrieval during installation or post-installation by specifying the Safe Name and Object Name for the credential. When needed during the boot-up sequence, or during normal operation (refreshing a service authentication) the Control Room will use the key vault connection to retrieve the credential and perform the required authentication (e.g. to SQL Database, or to Active Directory for authenticating users).

Retrieving Auto-login Credentials

Auto-login credentials are those credentials used to authenticate to the Bot agent Device for the purpose of starting an active Windows Session (required for RPA to work). Auto-login is performed when launching automations on a remote Bot agent Device. Either manually or as a scheduled job, a Control Room administrator can launch an automation on a Bot agent Device by specifying the name of the automation, the device, and a user context. For example, run the automation named ProcureToPayGeoEast on the device named WinVDI1138 as user Prior to starting the automation, the platform will check if there is currently an active Windows session on device WinVDI1138 and if that session belongs to robiticworkeer2112. If not, the system will instruct the Bot agent Device to perform a Windows Login on device WinVDI1138 as roboticworker2112 using the Auto-login credential for roboticworker2112. The automation (bot) ProcureToPayGeoEast then starts to run on WinVDI1138 as roboticworker2112.

Auto-login credential retrieval from the external key vault is configured by an administrator in the Control Room under Administration > Settings > Devices. If an external key vault connection is configured, there will be an option to configure Retrieve Auto-login credentials from external key vault. If this option in not present, the external key vault connection is not configured. If CyberArk is the configured external key vault, there will be an option to specify a Safe Name from where to retrieve the Auto-login Credentials. If the option to specify the Safe Name is not present, this means that CyberArk is not the configured external key Vault. The specified Safe Name is referred to as the Auto-login Credential Safe.

All Auto-login credentials will be retrieved from this Safe Name. All Auto-login credentials are assumed to be present within the Auto-login Credential Safe. If the system needs to perform Auto-login and there is no credential present in the Auto-login Credential Safe that matches the user for which the system is performing Auto-login, the Auto-login will fail. This means that for unattended automations, all robotic or digital worker user ids must have an Auto-login credential configured within the Auto-login Credential Safe.

Within the Auto-login Credential Safe, the Control Room will retrieve Auto-login credentials based on the Object naming convention within the safe. The Control Room will look for an object where the object name matches the Control Room user name for which it is performing Auto-login.

The naming convention for objects in the Auto-login Credential Safe that the Control Room expects is described in the table below:
Control Room user name Object name
ACME\akshay autologin_ACME--akshay autologin_bhavani@rpa-2e-acme-2e-com
For Auto-login credentials it is expected that the object name in the vault contains "autologin_" as a prefix. Certain key vaults have restrictions on the usage of certain characters, such as "\" and "@", in the secret name (object name) and restrictions on how special characters are interpreted within API calls. Auto-login credential names map to the login ID for the credential being retrieved, so if the user ID has special characters "\" or "@", the secret name (object name) must be encoded using the following substitutions:
  • "\" to "-"
  • "-" to "-2d-"
  • "_" to "-5f-"
  • "@" to "-2e-"
With the exception of the backslash being mapped to double dashes, the dash character, underscore and the "@" symbol are mapped using their ASCII code bracketed in dashes.

Retrieving Automation Credentials

Automation Credentials are simply a variable type used by bot developers within automation actions to define and retrieve data from encrypted storage. Automation Credentials are typically used by the automation to authenticate to applications but can be used for any purpose. Automation credentials are retrieved by the automation (bot) during runtime.

Automation Credentials retrieved from external key vaults are mapped within the Automation Anywhere Credential Vault using the External Key Vault button when configuring Lockers and Credentials. To configure Automation Credentials in CyberArk Password Vault, the Automation Anywhere Locker is mapped to a Safe Name and the credential is mapped to an Object Name.
Note: Any Automation Anywhere Locker can be mapped to any CyberArk Safe Name, the safe names used for mapping Automation Credentials should be considered distinct from the Safe Name used for Auto-login.

Access Controls within the Control Room, implemented via Automation Anywhere Roles, partition access to credentials by permitting access to a Locker. Controlling access to credentials is configured by assigning different Control Room users to different Roles and associating different lockers with those roles. By mapping different CyberArk safes to different lockers, access to credentials in CyberArk safes is mapped to and enforced by the access controls within the Automation Anywhere Platform via access permissions on Lockers.

Automation Anywhere Credential Vault supports two different types of credentials used for automation, System Credentials and User Defined Credentials:
System Credential
A credential where the value returned by the credential variable is the same for any automation that uses the variable.
User Defined Credential
A credential where the value returned by the credential variable is distinct based on the user context within which the automation is running.

User Defined Credentials allow automation developers to create automations that use a single credential variable but that retrieve different credential values during runtime depending on the user context within which the bot is running. User Defined Credentials simplify automation development (the code) by allowing the developer to write the code using a single credential variable where the platform will substitute the value returned during runtime with a unique user specific value. This means that developers do not need to use individual variables based on the user context or to duplicate code with different user specific credential variables.

To configure Automation Credentials with integration to CyberArk, create a Locker in the Control Room and use the External Key Vault option to specify the Safe Name in CyberArk. Next create a credential in the Control Room, specifying the Locker that is mapped to the Safe Name, and then the Object Name (object isin the same safe), in CyberArk. Within the Safe Name mapped to the Locker, Automation Anywhere will expect objects to be name based on the naming convention described in the table below.
Automation credential Safe name Object prefix Object in locker Control Room username
System credential in locker mapped to Safe Name finance glaccess glaccess None- system credential
User defined credential in locker mapped to SafeName finance glaccess glaccess_ACME--RPA--bhavani ACME\RPA\bhavani
User defined credential in locker mapped to SafeName where username is encoded with ASCII hex mapping finance glaccess glaccess_ACME--RPA-2e-bhavani ACME\RPA.bhavani
Refer to the character mapping/encoding notes in the Retrieving Auto-login Credentials above.

During runtime, the platform will retrieve the Object Name that is named with a postfix that matches the user context (the User Defined Credential) within which the bot is running. If there is no User Defined Credential, the platform will retrieve the Object Name without a user name postfix (the System Credential).

Additional resources

For more information about external key vaults, see the following topics:

Configure external key vault integration
Necessary configuration steps and prerequisites for setting up an external key vault.
Edit external key vault configuration
Editing a preexisting Control Room configuration.
Utility for key vault and database authentication configuration
More information on installation support for third-party key vaults.
Send Feedback