Integrating credential stores

CyberArk® CCP integration

The Central Credential Provider (CCP) is the agentless AAM method used to integrate with CyberArk allowing UiPath to securely retrieve credentials from a vault without deploying an agent on the server. A client certificate is necessary to ensure secure retrieval of the credential.

Before you can begin to use CyberArk® CCP credential stores in Orchestrator, you must first set up the corresponding application and safe settings in the CyberArk® PVWA (Password Vault Web Access) interface.

Prerequisites

• A network that allows for interconnectivity between the Orchestrator service and the CyberArk server.
• CyberArk® Central Credential Provider must be installed on a machine that allows HTTP connections.
• CyberArk® Enterprise Password Vault

For more information about installing and configuring CyberArk® applications, please visit their official page.

Configuring the integration

From the CyberArk® PVWA, you must perform the following steps:

1. Create an application for your Orchestrator instance and add client certificates;
2. Create a Safe and add members to it to ensure proper permissions.

Creating an Orchestrator application

1. In CyberArk®’s PVWA, log in with a user with permissions to manage applications (it requires Manage Users authorization).
2. In the Applications tab, click Add Application. The Add Application window is displayed.
   
   

   

   
   
3. On the Add Application window, specify the following information:
   • Name field - a custom name for the application, such as Orchestrator.
   • Description - a short description to help you specify the purpose of the new application.

   • Location - the path of the application within the Vault hierarchy. If a location is not specified, the application is added in the same location as the user who is creating this application.

     
     

     

     
     
4. Click Add. The application is added, and its details are displayed on the Application Details page.
5. Select the Allow extended authentication restrictions checkbox.

   Supported authentication method:

   • Client Certificates - the client certificate used for the CyberArk authentication should be at least 2048 bits
6. Configure the authentication method. For example, in the Authentication tab, click Add > Certificate Serial Number, and add the unique identifier of the client certificate, used to authenticate the requesting application against CCP.
   
   

   

   
   

Creating an Orchestrator safe

Safes are required to help you better manage your accounts. Also, you can add safe members to ensure proper authorization. CyberArk® recommends adding a credential provider (a user with full rights over the credentials can add and manage them) and the previously created application as safe members. The latter enables Orchestrator to find and retrieve the passwords stored in the safe.

1. In the Policies tab, under the Access Control (Safes) section, click Add Safe. The Add Safe page is displayed.
   
   

   

   
   
2. Fill in the Safe Name field and Description fields.
3. Click Save. The Safe Details window is displayed.
   
   

   

   
   
4. In the Members section, click Add Member. The Add Safe Member window is displayed.
   
   

   

   
   
5. Search for the previously created application (steps 2-6), and select the following permissions for it:
   • View Safe Members
   • Retrieve accounts
   • List accounts

   • Access Safe without Confirmation - Only if you are using a dual control environment and a v7.2 or lower PIM-PSM.

     If you install multiple credential providers for this integration, it is recommended to create a group for them and add the group to the Safe once with the above authorization.

     
     

     

     
     
6. Click Add. Your integration is complete, and you can begin provisioning CyberArk® credential stores in Orchestrator. For details on storing Robot credentials, see here.

Azure Key Vault integration

Azure Key Vault is a plugin you can use as a credential store with Orchestrator.

There are two plugins included:

• Azure Key Vault – a read-write plugin (secrets are created through Orchestrator)
• Azure Key Vault (read-only) – a read-only plugin (you must provision the secrets in the vault directly)

Prerequisites

• Azure Key Vault credential stores use RBAC authentication. Azure Key Vault requires the Key Vault Secrets Officer role, and Azure Key Vault (read-only) requires Key Vault Secrets User role.

Configuration

In the App Registrations pane of the Azure Portal, follow these steps:

1. Create a new app registration.
2. Copy the Application (Client) ID for later use.
3. Go to Manage > Certificates & Secrets > New client secret, and add a new client secret. Make a note of the expiration you chose and create a new secret before that.
4. Copy the Value of the secret for later use.

In the Azure Key Vault, follow these steps:

1. Access the Key Vault's Overview page, and copy the Vault URI and Directory ID for later use.
2. Select Settings > Access Policies from the menu on the left.
3. Click Add access policy.
   The required access policy permissions are Secret Get and Secret Set.
4. From the Configure from template (optional) drop-down menu, select Secret Management.
5. Click None selected in the Authorized application section to enable the Select principal field.
6. Enter the app registration name, confirm that the Application ID is correct, and select this principal.
7. Click Add.
8. Click Save.

You are now ready to use Vault URI,Directory ID,Application (Client) ID and the secret's Value to configure a new credential store.

Using Azure Key Vault (read-only)

When using Azure Key Vault (read-only) plugin, the Vault admin is responsible for correctly provisioning the secrets that Orchestrator will use. The format in which these secrets must be provisioned differs between secret types (asset versus robot password) and between secret engines.

For instructions on how to provision the secrets, see the following:

• Storing unattended robot credentials in Azure Key Vault (read-only)
• Storing assets in Azure Key Vault (read-only)

HashiCorp Vault integration

HashiCorp Vault is a plugin you can use as a credential store with Orchestrator.

There are two plugins included:

• HashiCorp Vault – a read-write plugin (secrets are created through Orchestrator)
• HashiCorp Vault (read-only) – a read-only plugin (you must provision the secrets in the vault directly)

Prerequisites

• A network that allows for interconnectivity between the Orchestrator service and the HashiCorp Vault server:

  • The API port used by HashiCorp Vault for API requests must be open through any firewall and reachable from the internet. That port is 8200 in a typical install.
  • If the customer's firewall does not allow connectivity from any internet IP, Orchestrator's IP addresses must be whitelisted. You can find an up-to-date list of IPs on the Orchestrator outbound IP addresses page.

• You must configure one of the supported authentication methods:

  • AppRole (recommended)
  • UsernamePassword
  • LDAP
  • Token

    See how to configure authentication.

• You must configure one of the supported secrets engines:

  • KeyValueV1 - available for both HashiCorp Vault and HashiCorp Vault (read-only)
  • KeyValueV2 - available for both HashiCorp Vault and HashiCorp Vault (read-only)
  • ActiveDirectory - available only for HashiCorp Vault (read-only)

  • OpenLDAP - available only for HashiCorp Vault (read-only)

• The chosen authentication method must have a policy that allows the following capabilities on the path where you plan to store your secrets:

  • For HashiCorp Vault (read-only) plugin: read
  • For HashiCorp Vault plugin: create, read, update, delete, and optionally delete on the metadata path, if using the KeyValueV2 secrets engine.

Configuring the integration

The following is an example of how to configure a development version of HashiCorp Vault, running in a docker container, to be used as a credential store with Orchestrator. The examples should be adapted to your own environment. Please consult the official documentation of HashiCorp Vault for details.

Configuring authentication

To start creating and reading secrets, you first need to configure the authentication method by taking the following steps:

1. Open a shell inside the container:

   docker exec -it dev-vault sh

2. Log in as root. Make sure you have the root token displayed in the logs to set an environment variable with it by running the following command:

   export VAULT_TOKEN=s.hA7RJ5lBqSnKUPd8nrQBaK1f

3. Check the Vault status by running the following command:

   vault status

4. Add a dummy secret for Orchestrator in the KV store:

   vault kv put secret/applications/orchestrator/testSecret supersecretpassword=123456

5. Give Orchestrator access to the newly created secret/applications/orchestrator path. For this, you must first create a policy for reading and writing to this path and all its subpaths by running the following command:

   cat <<EOF | vault policy write orchestrator-policy -
   path "secret/data/applications/orchestrator/*" {
     capabilities = ["create", "read", "update", "delete"]
   }
   path "secret/metadata/applications/orchestrator/*" {
     capabilities = ["delete"]
   }
   EOF

   Note:

   When using a KeyValueV2 secrets engine , secrets are written and fetched at path <mount>/data/<secret-path>, as opposed to <mount>/<secret-path> in KeyValueV1. It does not change any of the CLI commands (i.e., you do not specify data in your path).

   However, it does change the policies, since capabilities are applied to the real path. In the previous example, the path is secret/data/applications/orchestrator/* since we are working with a KeyValueV2 secrets engine. If a KeyValueV1 were used, the path would have been secret/applications/orchestrator/*.

   The capability to delete on the metadata path is needed only if you want to ensure Orchestrator does not leave behind test keys when verifying connectivity. If this capability is not granted, then a key will be created and left behind when creating the Credential Store in Orchestrator.

6. Enable authentication using the userpass authentication method, then create a user for Orchestrator and assign the previously created policy:

   vault auth enable userpass
   vault write auth/userpass/users/orchestrator password=123456 policies=orchestrator-policy

   Note: Orchestrator supports multiple authentication modes. See the HashiCorp Vault documentation for how to configure them.
7. Check that you have configured everything correctly by logging in and trying to read the secret you created earlier:

   vault login -method=userpass username=orchestrator password=123456

   Output of this command:

   WARNING! The VAULT_TOKEN environment variable is set! This takes precedence
   over the value set by this command. To use the value set by this command,
   unset the VAULT_TOKEN environment variable or set it to the token displayed
   below.
   Success! You are now authenticated. The token information displayed below
   is already stored in the token helper. You do NOT need to run "vault login"
   again. Future Vault requests will automatically use this token.
   Key                    Value
   ---                    -----
   token                  s.nwombWQH3gGPDhJumRzxKqgI
   token_accessor         aGJL6Pzc6fRRuP8d8tTjS2Kj
   token_duration         768h
   token_renewable        true
   token_policies         ["default" "orchestrator-policy"]
   identity_policies      []
   policies               ["default" "orchestrator-policy"]
   token_meta_username    orchestratorWARNING! The VAULT_TOKEN environment variable is set! This takes precedence
   over the value set by this command. To use the value set by this command,
   unset the VAULT_TOKEN environment variable or set it to the token displayed
   below.
   Success! You are now authenticated. The token information displayed below
   is already stored in the token helper. You do NOT need to run "vault login"
   again. Future Vault requests will automatically use this token.
   Key                    Value
   ---                    -----
   token                  s.nwombWQH3gGPDhJumRzxKqgI
   token_accessor         aGJL6Pzc6fRRuP8d8tTjS2Kj
   token_duration         768h
   token_renewable        true
   token_policies         ["default" "orchestrator-policy"]
   identity_policies      []
   policies               ["default" "orchestrator-policy"]
   token_meta_username    orchestrator

8. Take this token and set it instead of the root token, then try to read the test secret:

   export VAULT_TOKEN=s.nwombWQH3gGPDhJumRzxKqgI
   vault kv get secret/applications/orchestrator/testSecret

Output of this command:

====== Metadata ======
Key              Value
---              -----
created_time     2020-10-12T06:24:41.7827631Z
deletion_time    n/a
destroyed        false
version          1
=========== Data ===========
Key                    Value
---                    -----
supersecretpassword    123456====== Metadata ======
Key              Value
---              -----
created_time     2020-10-12T06:24:41.7827631Z
deletion_time    n/a
destroyed        false
version          1
=========== Data ===========
Key                    Value
---                    -----
supersecretpassword    123456

Note:

You can also enable appRole Orchestrator by running the following command:

/ # vault auth enable approle 
/ # vault write auth/approle/role/orchestrator policies=orchestrator-policy 
/ # vault read auth/approle/role/orchestrator/role-id 
/ # vault write -f auth/approle/role/orchestrator/secret-id

You will now have a role-id and secret-id for configuring in Orchestrator.

Configuring the Active Directory Secrets Engine

To configure the Active Directory secrets engine, take the following steps:

1. Enable the Active Directory secrets engine by running the following command:

   vault secrets enable ad

2. Configure the credentials that HashiCorp Vault uses to communicate with Active Directory to generate passwords:

   vault write ad/config \
       binddn=$USERNAME \
       bindpass=$PASSWORD \
       url=ldaps://138.91.247.105 \
       userdn='dc=example,dc=com'

3. Configure a role that maps a name in HashiCorp Vault to an account in Active Directory. When applications request passwords, password rotation settings will be managed by this role.

   vault write ad/roles/orchestrator service_account_name="[e-mail]"

4. Grant orchestrator access to its credentials at ad/creds/orchestrator using an authentication method, such as AppRole.

   cat <<EOF | vault policy write orchestrator-policy -
   path "ad/creds/orchestrator" {
     capabilities = ["read"]
   }
   EOF

Using HashiCorp Vault (read-only)

When using HashiCorp Vault (read-only) plugin, the Vault admin is responsible for correctly provisioning the secrets that Orchestrator will use. The format in which these secrets must be provisioned differs between secret types (asset versus robot password) and between secret engines.

For instructions on how to provision the secrets, see the following:

Storing unattended robot credentials in HashiCorp Vault (read-only)

Storing assets in HashiCorp Vault (read-only)

BeyondTrust integration

The BeyondTrust integration is read-only and comes in the form of two plugins you can choose from: BeyondTrust Password Safe - Managed Accounts and BeyondTrust Password Safe - Team Passwords.

While BeyondTrust Password Safe - Managed Accounts addresses the needs of organizations with either local or Active Directory accounts, BeyondTrust Password Safe - Team Passwords is suitable in scenarios where the credentials of small groups must be stored in an isolated environment.

The configuration of the two plugins is mostly identical, but there are some slight differences as well. This page covers both plugins.

Prerequisites

• A BeyondTrust Server Cloud instance or a similar on-premises installation
• Beyond Insight credentials

Configuring the integration

1. Log in to the BeyondTrust Server Cloud instance or a similar on-premises installation using your Beyond Insight credentials.
2. Create an API Registration for UiPath Group of Service Accounts.
   
   

   

   
   
3. Create an Authentication Rule to allow incoming API connections from UiPath.
   
   

   

   
   
4. Create a new Group for UiPath Service Account(s) and add the following features:
   • Password Safe Account

   • Password Safe Role

     
     

     

     
     
5. You also need to assign Smart Rules:
   • Managed Accounts/Read-Only/Requester are sufficient for regular User Requests

   • For ISA access, Assets/ISA role is needed.

     
     

     

     
     
6. Add the API Registration to the Group.
   
   

   

   
   
7. Create a new User and assign the UiPath Group.
   
   

   

   
   
8. The following steps vary based on whether you are using BeyondTrust Password Safe - Managed Accounts or BeyondTrust Password Safe - Team Passwords.

BeyondTrust Password Safe - Managed Accounts

If you are using BeyondTrust Password Safe - Managed Accounts, continue with the following steps:

1. Add your Managed Accounts under Managed Systems.
   

   

   
   

2. Make sure to use API Enabled for your Managed Accounts.

BeyondTrust Password Safe - Team Passwords

If you are using BeyondTrust Password Safe - Team Passwords, continue with the following steps:

1. Go to the Team Passwords page.
   

   

   
   

2. Optionally create a new Folder.

3. Select a Folder.
4. Use the Create New Credential option.

Thycotic Secret Server integration

Note: Thycotic has been rebranded as Delinea as a result of a merger. Please keep this in mind when configuring your credential store integrations.

Prerequisites

• A Thycotic Secret Server cloud instance or on-premises installation.

Configuring the integration

Important:

Make sure to read through the Delinea documentation for up-to-date information.

1. Log in to your Secret Server account.
2. Go to Admin > User Management and click Create User. Select the Application Account checkbox to generate an application account.
3. Navigate to Admin > See All > Tools and Integrations > SDK Client Management and set up a new onboarding rule in Client Onboarding. Note the onboarding rule name and key.
4. Edit the onboarding rule and assign the application account created at step 2.
5. Ensure the application account linked to the onboarding rule has permissions to the secrets accessed by Orchestrator. You can assign the application account to a group and grant that group access to the required folders, or grant it explicit access to the secrets.

AWS Secrets Manager integration

About AWS Secrets Manager

AWS Secrets Manager is a tool that can be used as a credential store in Orchestrator.

It features two plugins:

• AWS Secrets Manager
• AWS Secrets Manager (read only)

The plugin you can use, namely read-only or read-write, is dictated by your AWS Identity and Access Management (IAM) policy permissions.

If you choose to use the read-only plugin, you must link an asset to a set of credentials that is already available in the AWS Secrets Manager.

Prerequisites

To use this service:

• You need to have an AWS subscription.
• You need to create an IAM policy specific to the Secrets Manager, which you assign to the account's IAM role or user.

Configuration

To integrate AWS Secrets Manager with Orchestrator, you need the access key and the secret key that are generated once you create an AWS IAM account.

• The Access key ID can be found on the Security credentials tab of your AWS IAM account.

• The Secret key ID is only provided after you create the account. It is therefore important to copy it for future use.

  If you misplace of forget your secret key ID, you need to create another access key, then replace the necessary information in Orchestrator.

In addition to that, you need to check the region you set in your AWS account, as this is what you will enter in the Region field while configuring the new credential store.

Using AWS Secrets Manager (read Only)

When using the AWS Secrets Manager (read only) plugin, the administrator is responsible for correctly provisioning the secrets that Orchestrator will use. The format in which these secrets must be provisioned differs between secret types (asset versus robot password) and between secret engines.

For instructions on how to provision the secrets, see the following:

• Storing unattended robot credentials in AWS Secrets Manager (read only)
• Storing assets in AWS Secrets Manager (read only)