# Integrating credential stores

> 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.

## 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](https://www.cyberark.com/resources/).

### 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.

Figure 1. Add Application window

![Screenshot of the Add Application window](https://dev-assets.cms.uipath.com/assets/images/orchestrator/orchestrator-screenshot-of-the-add-application-window-226787-8c83c3a5-020e7747.webp)

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. Select **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, select **Add** > **Certificate Serial Number**, and add the unique identifier of the client certificate, used to authenticate the requesting application against CCP.

Figure 2. Certificate Serial Number

![Screenshot of the certificate serial number](https://dev-assets.cms.uipath.com/assets/images/orchestrator/orchestrator-screenshot-of-the-certificate-serial-number-227187-85a534cb-1d6d6733.webp)

### 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.

Figure 3. Add Safe page

   ![Screenshot of the Add Safe page](https://dev-assets.cms.uipath.com/assets/images/orchestrator/orchestrator-screenshot-of-the-add-safe-page-232053-d2368ef6-4bdee53b.webp)

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

Figure 4. Safe Details window

   ![Screenshot of the Safe Details window](https://dev-assets.cms.uipath.com/assets/images/orchestrator/orchestrator-screenshot-of-the-safe-details-window-233175-1ba0cca9-8af77e36.webp)

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

Figure 5. Members window

   ![Screenshot of the Members window](https://dev-assets.cms.uipath.com/assets/images/orchestrator/orchestrator-screenshot-of-the-members-window-231210-c4dedf91-f95ac47d.webp)

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.

Figure 6. Add Safe Member window

   ![Screenshot of the Add Safe Member window](https://dev-assets.cms.uipath.com/assets/images/orchestrator/orchestrator-screenshot-of-the-add-safe-member-window-232161-5e07b611-b468df30.webp)

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](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/storing-credentials-in-cyberark#storing-robot-credentials-in-cyberark).

## CyberArk® Conjur (read-only)

:::tip
Compared to **CyberArk Conjur Cloud (read-only)**, this credential store supports an extra authentication method, **Jwt**. You can also use this plugin for both [CyberArk Secrets Manager SaaS](https://docs.cyberark.com/secrets-manager-saas/latest/en/content/resources/_topnav/cc_home.htm) and [CyberArk Secrets Manager Self-Hosted](https://docs.cyberark.com/secrets-manager-saas/latest/en/content/resources/_topnav/cc_home.htm). This allows you to integrate with identity providers and use token-based authentication for improved security and flexibility.
:::

You can use this plugin for both [CyberArk Secrets Manager - SaaS](https://docs.cyberark.com/secrets-manager-saas/latest/en/content/resources/_topnav/cc_home.htm) and [CyberArk Secrets Manager, Self-Hosted](https://docs.cyberark.com/secrets-manager-sh/latest/en/content/resources/_topnav/cc_home.htm). It allows organizations to secure non-human access to secrets and eliminate the secret-zero problem. To use the CyberArk® Conjur (read-only) plug-in in Orchestrator, you must set up the corresponding safe settings in the CyberArk® Privilege interface.

### Prerequisites

* A network that allows for interconnectivity between the Orchestrator machines and the CyberArk® server.
* A CyberArk® Privilege user with access to create users and safes.
* A CyberArk® Privilege user with permissions to the required safes, and the ability to create workloads.

For more information about configuring CyberArk® applications, visit the official documentation.

### Create an Orchestrator safe for storing credentials

1. In CyberArk® Privilege Cloud, log in with an account with permissions to manage applications (it requires **Manage Users** authorization).
2. Next to the **User Portal**, select **Home**.
3. Under **Privilege Cloud**, select **Policies,** then **Safes**, and then **Create Safe**, and add the following information:
   1. On the **Define properties** step, add a custom name for the safe and select **Next**.
   2. On the **Select members** step, select **System Component Users** for **Source**, search for **Conjur Sync**, select the **Conjur Cloud** user, then select **Next**.
   3. On the **Set Safe permissions** step, select **Full** for **Permissions Presets**, then select **Create Safe**.
4. The new safe is now visible under **Policies**, after selecting **Safes**.

### Create an account and workload to access the credentials

To access the safes you created in CyberArk®, you also need an account in **Privilege Cloud** and a workload in **Secrets Manger**.

1. Under **Privilege Cloud**, select **Accounts**, then **Add account**, and then:
   1. On the **Select system type** step, select **Windows**, then **Windows Domain Account**, and then select an existing safe.
   2. On the **Define account properties** step, fill in the **Address**, **Username**, and **Password** fields.
   3. Enable the **Customize account name** option, if you want to add a custom name for the account.
      :::note
      When an asset or robot is created in Orchestrator, it is linked to an existing secret using the **External Name**. Make sure that, in Orchestrator, either the generated or the customized account name is set in the **External Name** field, to be mapped with the CyberArk® account details. For example, the format `data/vault/OrchestratorQA/companyname-john.doe/username` represents a customized account name, while the format `data/vault/OrchestratorQA/Operating System-WinDomain-adress-test (1)/address` represents a generated account name.
      :::
2. Once you have created a safe and an account, go to the **Secrets Manager** service, select **Workloads**, then **Create workload**.
   1. On the **Workload type** step, select **Other**.
   2. On the **Workload Details** step, enter a custom name for the workload in the **Name** field, and select **data** for the **Branch** field.
   3. Under **Authentication**, select **Jwt** from the **Authenticator type** dropdown.
   4. On the **Access to Safes** step, select the previously created safe.
   5. Check the summary of your configuration, then select **Done**.
   6. You can copy the API key, then select **Done**.

For instructions on how to provision the secrets, check the following page:
   * [Storing Robot credentials in CyberArk](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/storing-credentials-in-cyberark)

## CyberArk® Conjur Cloud (read-only)

CyberArk® Secrets Manager - SaaS is a SaaS-based, cloud-agnostic solution for secrets management. It allows organizations to secure non-human access to secrets and eliminate the secret-zero problem. To use the CyberArk® Conjur Cloud (read-only) plug-in in Orchestrator, you must set up the corresponding safe settings in the CyberArk® Privilege Cloud interface.

### Prerequisites

* A network that allows for interconnectivity between the Orchestrator machines and the CyberArk® server.
* A CyberArk® Privilege Cloud user with access to create users and safes.
* A CyberArk® Privilege Cloud user with permissions to the required safes, and the ability to create workloads.

For more information about configuring CyberArk® Secrets Manager - SaaS applications, visit their official documentation.

### Create an Orchestrator safe for storing credentials

1. In CyberArk® Privilege Cloud, log in with an account with permissions to manage applications (it requires **Manage Users** authorization).
2. Next to the **User Portal**, select **Home**.
3. Under **Privilege Cloud**, select **Policies,** then **Safes**, and then **Create Safe**, and add the following information:
   1. On the **Define properties** step, add a custom name for the safe and select **Next**.
   2. On the **Select members** step, select **System Component Users** for **Source**, search for **Conjur Sync**, select the **Conjur Cloud** user, then select **Next**.
   3. On the **Set Safe permissions** step, select **Full** for **Permissions Presets**, then select **Create Safe**.
4. The new safe is now visible under **Policies**, after selecting **Safes**.

### Create an account and workload to access the credentials

To access the safes you created in CyberArk®, you also need an account in **Privilege Cloud** and a workload in **Secrets Manager**.

1. Under **Privilege Cloud**, select **Accounts**, then **Add account**, and then:
   1. On the **Select system type** step, select **Windows**, then **Windows Domain Account**, and then select an existing safe.
   2. On the **Define account properties** step, fill in the **Address**, **Username**, and **Password** fields.
   3. Enable the **Customize account name** option, if you want to add a custom name for the account.
      :::note
      When an asset or robot is created in Orchestrator, it is linked to an existing secret using the **External Name**. Make sure that, in Orchestrator, either the generated or the customized account name is set in the **External Name** field, to be mapped with the CyberArk® account details. For example, the format `data/vault/OrchestratorQA/companyname-john.doe/username` represents a customized account name, while the format `data/vault/OrchestratorQA/Operating System-WinDomain-adress-test (1)/address` represents a generated account name.
      :::
2. Once you have created a safe and an account, go to the **Secrets Manger** service, select **Workloads**, then **Create workload**.
   1. On the **Workload type** step, select **Other**.
   2. On the **Workload Details** step, enter a custom name for the workload in the **Name** field, and select **data** for the **Location** field.
   3. Under **Authentication**, select **API key**.
   4. On the **Access to Safes** step, select the previously created safe.
   5. Check the summary of your configuration, then select **Done**.
   6. You can copy the API key, then select **Done**.

For instructions on how to provision the secrets, check the following page:
   * [Storing Robot credentials in CyberArk](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/storing-credentials-in-cyberark)

## 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 Azure role-based access control (RBAC) authentication. Assign the appropriate role to the service principal associated with your app registration, depending on the type of credential store:
  + For read-write credential stores, assign the **Key Vault Secrets Officer** role.
  + For read-only credential stores, assign the **Key Vault Secrets User** role.
* In Automation Cloud Public Sector and Test Cloud Public Sector, you can only use an Azure Key Vault that is hosted by [Azure Government](https://learn.microsoft.com/en-us/azure/azure-government/).

### 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 **Access Control (IAM)** from the menu on the left.
3. Select **Add**, and then select **Add role assignment**.
4. Select one of the following roles, depending on your credential store type:
   * **Key Vault Secrets Officer** for read-write credential stores.
   * **Key Vault Secrets User** for read-only credential stores.
5. Assign the role to the service principal associated with your app registration.
6. Select **Review + assign** to save the role assignment.

#### 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)](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/storing-unattended-robot-passwords-in-azure-key-vault-read-only#storing-unattended-robot-passwords-in-azure-key-vault-(read-only))
* [Storing assets in Azure Key Vault (read-only)](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/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](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/orchestrator-outbound-ip-addresses#orchestrator-outbound-ip-ranges) page.
* You must configure one of the supported authentication methods:
  + **AppRole** (recommended)
  + **UsernamePassword**
  + **LDAP**
  + **Token**See how to [configure authentication](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/integrating-credential-stores#configuring-the-integration).
* 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](https://www.vaultproject.io/docs) 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 Value=123456
   ```
5. Give Orchestrator access to the newly created `secret/applications/orchestrator` path. For this, you must first create a [policy](https://www.vaultproject.io/docs/concepts/policies) 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](https://www.vaultproject.io/docs/auth), 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](https://www.vaultproject.io/docs/auth/userpass) 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](https://www.vaultproject.io/docs/auth/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="my-application@example.com"
   ```
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)](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/storing-unattended-robot-credentials-in-hashicorp-vault-read-only#storing-unattended-robot-credentials-in-hashicorp-vault-(read-only))

[Storing assets in HashiCorp Vault (read-only)](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/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.

Figure 7. Creating an API Registration

   ![Screenshot of the BeyondTrust configuration page](https://dev-assets.cms.uipath.com/assets/images/orchestrator/orchestrator-screenshot-of-the-beyondtrust-configuration-page-225698-521df759-c7f36028.webp)

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

Figure 8. Creating an Authentication Rule

   ![Screenshot of the BeyondTrust configuration page](https://dev-assets.cms.uipath.com/assets/images/orchestrator/orchestrator-screenshot-of-the-beyondtrust-configuration-page-226204-150a899c-e2d3b4fb.webp)

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

Figure 9. Creating a new Group

   ![Screenshot of the BeyondTrust Group Details page](https://dev-assets.cms.uipath.com/assets/images/orchestrator/orchestrator-screenshot-of-the-beyondtrust-group-details-page-231206-7b06e50c-ddb89795.webp)

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.

Figure 10. Assigning Smart Rules

   ![Screenshot of the BeyondTrust Group Permissions page](https://dev-assets.cms.uipath.com/assets/images/orchestrator/orchestrator-screenshot-of-the-beyondtrust-group-permissions-page-229773-1e23edf4-9c6423aa.webp)

6. Add the **API Registration** to the Group.

Figure 11. Adding the API Registration to the Group

   ![Screenshot of the BeyondTrust Group Details page](https://dev-assets.cms.uipath.com/assets/images/orchestrator/orchestrator-screenshot-of-the-beyondtrust-group-details-page-231088-26c34292-e0ba7793.webp)

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

Figure 12. Creating a new user

   ![Screenshot of the BeyondTrust Groups page](https://dev-assets.cms.uipath.com/assets/images/orchestrator/orchestrator-screenshot-of-the-beyondtrust-groups-page-225937-d8533332-86ebe86f.webp)

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**.

Figure 13. Managed Systems page

   ![Screenshot of the BeyondTrust Managed Systems page](https://dev-assets.cms.uipath.com/assets/images/orchestrator/orchestrator-screenshot-of-the-beyondtrust-managed-systems-page-227527-7ae976ea-54b120ce.webp)

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

Figure 14. Managed Accounts page

   ![Screenshot of the BeyondTrust Managed Accounts page](https://dev-assets.cms.uipath.com/assets/images/orchestrator/orchestrator-screenshot-of-the-beyondtrust-managed-accounts-page-226507-adec03a9-92d7c05f.webp)

#### 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.

Figure 15. Team Passwords page

   ![Screenshot of the BeyondTrust Credentials page](https://dev-assets.cms.uipath.com/assets/images/orchestrator/orchestrator-screenshot-of-the-beyondtrust-credentials-page-232133-10d6b836-b69ac6f5.webp)
   
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](https://delinea.com/news/thycoticcentrify-is-now-delinea) as a result of a merger. Please keep this in mind when configuring your credential store integrations.
:::

:::important
The **Thycotic Secret Server** integration is being succeeded by the new [Delinea Secret Server integration](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/integrating-credential-stores#delinea-secret-server-integration), which adheres to the latest Delinea recommendations. We highly encourage you to migrate existing Thycotic credential stores to the new Delinea integration.
:::

### Prerequisites

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

### Configuring the integration

:::important
Make sure to read through the [Delinea documentation](https://docs.delinea.com/online-help/integrations/uipath/setup/index.htm) for up-to-date information.
:::

1. Log in to your Secret Server account.
2. Go to **Admin** &gt; **User Management** and click **Create User**. Select the **Application Account** checkbox to generate an application account.
3. Navigate to **Admin** &gt; **See All** &gt; **Tools and Integrations** &gt; **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.

## Delinea Secret Server integration

:::note
**Delinea Secret Server (read only)** is a read-only credential store. Orchestrator can retrieve asset values and robot credentials from it, but cannot create, update, or delete secrets.
:::

The Delinea Secret Server integration is the successor to the [Thycotic Secret Server integration](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/integrating-credential-stores#thycotic-secret-server-integration). Both integrations share the same underlying SDK and the same rule-based onboarding mechanism, making it easy to migrate existing Thycotic credential stores to the new Delinea store. The Delinea integration adheres to the latest third-party recommendations and is suitable for organizations that have migrated to the latest Delinea platform version.

### Prerequisites

* A Delinea Secret Server cloud instance or on-premises installation, with access to both the Delinea platform URL and the Secret Server URL during the platform migration.
* A Delinea user account with permissions to manage **SDK Client Management** and to create secrets.

### Configuring the integration

:::important
Make sure to read through the [Delinea documentation](https://docs.delinea.com/online-help/integrations/uipath/setup/index.htm) for up-to-date information.
:::

#### Enable SDK Client Management

In the Delinea admin console, navigate to **Admin** > **SDK Client Management** > **Configuration** and enable SDK client management. Without this, the rule-based onboarding will fail.

#### Set up a service user
Navigate to the **Users** page, and set up a new service user. We will control the access rights for a secret via this identity later.

#### Create an onboarding rule

1. Go to **Admin** > **SDK Client Management** > **Client Onboarding** and create a new rule.
2. Set a **Rule Name** and, optionally, enable **Require onboarding key**, which generates a **Rule Key**.
3. Add the previously created service user to this rule.
4. Note down both the **Rule Name** and **Rule Key**. You need them when configuring the credential store in Orchestrator.

#### Create a secret and grant access

1. Create a secret using the **Generic Discovery Credentials** template, or any template with username and password fields.
2. Open the secret, go to the **Sharing** tab, select **Edit**, and disable **Inherit Permissions**.
3. Add the service user associated with your SDK rule, and grant it at least **View** access.
4. Note the numeric **Secret ID** from the URL. This is the **External Name** you use in Orchestrator assets and robot credentials.

## AWS Secrets Manager integration

### About AWS Secrets Manager

[AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 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)](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/storing-unattended-robot-credentials-in-aws-secrets-manager-read-only#storing-unattended-robot-credentials-in-aws-secrets-manager-(read-only))
* [Storing assets in AWS Secrets Manager (read only)](https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/storing-assets-in-aws-secrets-manager-read-only)

## Google Secret Manager

Google Secret Manager is a plugin you can use as a credential store with Orchestrator.

There are two plugins included:

* **Google Secret Manager** - a read-write plugin that allows you to create and manage secrets directly from Orchestrator.
* **Google Secret Manager (read-only)** - a read-only plugin that only allows you to consume existing secrets. Secrets must be provisioned directly in Google Secret Manager.

### Prerequisites

You need a [Google Cloud](https://console.cloud.google.com/) project with a **Secret Manager** component to connect Orchestrator to Google Secret Manager.

### Configure the integration

To connect Orchestrator to Google Secret Manager, proceed with the following steps:

1. Enable the **Secret Manager API**.
2. Create a service account and generate a service account key.
3. Add a Google Secret Manager credential store in Orchestrator.

#### Step 1: Enable Secret Manager API

1. Select **Select a project** to get to the projects list and choose the desired project.
2. In the search bar, search for **Secret Manager** and open **Secret Manger** from the results list.
3. Select **Enable** under **Secret Manager API**.

#### Step 2: Create a service account and generate a service account key

1. In the search bar, search for **Service Accounts** and open **Service Accounts** from the results list.
2. Select **Create service account**.
   1. Type a name for the new service account and select **Create and continue**.
   2. In the **Permissions (optional)** step, assign the **Secret Manager Admin** role to the new service account.
   3. Select **Continue** and then **Done**.
3. From the service accounts list, select the new account.
4. Navigate to the **Keys** tab.
5. Select **Add key** and choose **Create new key**.
   1. Choose **JSON**.
   2. Select **Create**.At the end of this step, a JSON file is downloaded. Save this file as you will need it when configuring the Credential Store.

#### Step 3: Add Google Secret Manager to Orchestrator

1. Navigate to the **Tenant** page in Orchestrator.
2. Select **Credentials** and go to the **Stores** tab.
3. Select **Add credentials store**.
4. Choose **Google Secret Manager** from the **Type** drop-down menu.
5. Type in a name for your Credentials Store.
6. In the **Google Cloud Project ID** field, type in the **Project ID** of your Google Cloud project.
7. In the **Service Account Key json** field, upload the JSON downloaded at the previous step.
8. Select **Create**.
   :::important
   * When retrieving an asset from a Google Secret Manager credential store (read-write or read-only), the latest secret version
   will always be retrieved. Ensure that the latest version is the correct one.
   * If the latest secret version is disabled, retrieval will fail. Ensure that the latest secret version is enabled.
   :::

### Using Google Secret Manager

When creating assets in a read-write credential store, asset names must only contain English characters (`A-Z, a-z`), numbers (`0-9`), dashes (`-`), and underscores (`_`).

Invalid characters are automatically replaced with `_`.

### Using Google Secret Manager (read-only)

#### Storing assets in a read-only credential store

When storing an asset of type **Credential** in a **Google Secret Manager (read only)** credential store, you must create the secret in Secret Manager with:

* The **Asset Name** of the secret must be an exact match with the **External Name** configured in Google Secret Manager.
* Google Secret Manager can only contain letters (`A-Z, a-z`), numbers (`0-9`), dashes (`-`), and underscores (`_`).
* The secret value must be saved as a **Secret Version** with the following JSON structure:
  ```
  {"Username": "user", "Password": "pass"}
  ```

#### **Storing unattended robot passwords**

When storing an unattended robot password in a **Google Secret Manager (read only)** credential store, you must create the secret in Secret Manager with:

* The secret name must match the **External Name** for that robot.
* If no External Name is configured, the **Username** field is used instead, with invalid characters replaced by `_`.
* The secret value must contain only the password for the robot.