Managing credential stores

Creating a credential store

1. Click Add credential store on the Credentials page, in the Stores section. The Add Credential Store dialog appears.
2. From the Proxy drop-down, select the desired proxy. Local contains all Orchestrator built-in stores. Any other available options constitute proxies created by you on the Add Credentials Proxy page. As such, you can also have:

   • A connected proxy - this is managed by Orchestrator, meaning that Orchestrator retrieves credentials from the proxy and passes them on to the robot.

   • A disconnected proxy - this is not managed by Orchestrator, meaning that credentials are retrieved directly from the proxy before being passed on to the robot.

3. From the Type drop-down, select which secure store is used.
   The available options depend on the selected proxy.
   Note: If no valid plugins are configured, this field is empty.
4. The next steps will vary based on the credential store you want to create. Your options are:
   • Orchestrator Database
     Note: You can only have one Orchestrator Database store.
   • CyberArk® Conjur Cloud
   • Azure Key Vault – Choose between Azure Key Vault and Azure Key Vault (read-only)
   • HashiCorp Vault – Choose between HashiCorp Vault and HashiCorp (read-only)
   • BeyondTrust – Choose between BeyondTrust Password Safe - Managed Accounts and BeyondTrust Password Safe - Team Passwords
   • Thycotic Secret Server
   • AWS Secrets Manager – Choose between AWS Secrets Manager and AWS Secrets Manager (read only)

Orchestrator Database

Click Create - Orchestrator database stores do not have any configurable properties.

CyberArk CCP

Note: A CyberArk store configured in multiple tenants using the same App ID, Safe, and Folder Name, will permit access to stored credentials across tenants. To maintain tenant-level security and isolation, ensure different configurations are used for each tenant's CyberArk store.

1. In the Name field, type a name for the new credential store.
2. In the App ID field, enter the application ID for your Orchestrator instance from the CyberArk® PVWA (Password Vault Web Access) interface. See here for details.
3. In the CyberArk Safe field, enter the safe name defined in the CyberArk® PVWA. See here for details.
4. In the CyberArk Folder field, enter the location in which CyberArk® stores your credentials.
5. In the Central Credential Provider URL field, enter the Central Credential Provider's address.
6. In the Web Service Name field, enter the name of the Central Credential Provider web service. If you leave this field empty, the default name is used: AIMWebService.
7. The Client Certificate needs to be configured when the the CyberArk Application uses the client certificate authentication method. The expected input is a .pfx file which stores the private and the public key of the certificate. The client certificate needs to be installed on the machine where CyberArk CCP AIMWebservice is deployed.
   Note:

   The client certificate is used by CyberArk credential provided to authenticate the application defined in Orchestrator credential store. See the official CyberArk documentation for details on application authentication methods.

   The client certificate is a PKCS12 binary format file that stores the certificate chain public key(s) and the private key.

   CyberArk CCP uses 2048-bit certificate keys.

   If the client certificate is encoded in base 64 then run the following certutil command to decode it in binary format:

   certutil -decode client_certificate_encoded.pfx client_certificate.pfx

8. In the Client Certificate Password field, enter the password of the client certificate.
9. The Server Root Certificate needs to be configured when a self signed Root CA certificate is used by the CyberArk CCP AIMWebService for incoming HTTP requests. It is used in HTTPS TLS handshake certificate chain validation. The expected input is a .crt or .cer file which stores the root CA certificate public key.
10. The Allow OS User Authentication option is only displayed when the value of the parameter Plugins.SecureStores.CyberArkCCP.EnableOsUserAuthentication is set to true. The option allows authentication using the credentials of the user currently logged on to the Orchestrator machine.
    Note: Ensure the appropriate infrastructure is established by making the necessary changes in IIS for both Orchestrator and CyberArk.
11. Select Create. Your new credential store is ready for use.
    
    

    

    
    

CyberArk Conjur Cloud (read-only)

Note:

A CyberArk Conjur Cloud store configured with the same app ID, safe, and folder name across tenants allows cross-tenant credential access. To maintain tenant-level security and isolation, make sure you use different configurations for each CyberArk® Conjur Cloud store tenant.

1. In the Name field, type a name for the new credential store.
2. In the CyberArk Conjur Cloud URL field, add your private CyberArk URL (e.g. https://[your-company-name].secretsmgr.cyberark.cloud).
3. In the Login name field, copy the full workload name from CyberArk Conjur Cloud and paste it in Orchestrator in the host/data/<Workload_name> format.
4. In the API key field, add the API key generated while creating the workload. If you ever forget the API key, you can always generate a new one from Conjur Cloud, but make sure to also change it in Orchestrator.
5. In the optional Variable ID Prefix field, enter a prefix to be added to a variable path that you want to access. For example, data/vault/<Safe_Name>.
   Note: The prefix is added to the External Name field of the robot or asset when using a storage.

   For example, if we use the prefix /data/vault/Safe_Name and the external name Machine, the variables to be read are /data/vault/Safe_Name/Machine/username and /data/vault/Safe_Name/Machine/password.

Azure Key Vault

Key Vault credential stores use RBAC type authentication. After you've created a service principal, perform these steps:

1. In the Name field, type a name for the new credential store.
2. In the Key Vault Uri field, enter the address of your Azure Key Vault. This is https://<vault_name>.vault.azure.net/.
3. In the Directory ID field, enter the directory ID found in the Azure portal.
   
   
   
   
4. In the Client Id field, enter the Application ID from your Azure AD App Registrations section where the Orchestrator app was registered.
5. In the Client Secret field, enter the secret needed to authenticate the client account entered in the previous step.
6. Select Create. Your new credential store is ready for use.

Note:

When you access an Azure Key Vault from a different cloud than the public one, you must set the environment variable AZURE_AUTHORITY_HOST to the corresponding value (i.e. "AZURE_AUTHORITY_HOST": "https://login.microsoftonline.us/"). For more details on the values, check the Microsoft Entra authentication & national clouds - Microsoft identity platform documentation.

HashiCorp Vault

1. In the Type field, select HashiCorp Vault or HashiCorp Vault (read-only) as your credential store.
2. In the Name field, specify a name for the HashiCorp Vault credential store.
3. In the Vault Uri field, indicate the URI to the HTTP API of HashiCorp Vault.

4. In the Authentication Type field, indicate your preferred authentication method. Depending on the option you choose, you must configure additional fields:

   • AppRole – This is the recommended authentication method. If you choose this option, make sure to also configure the following fields:

     • Role Id – Indicate the role ID to use with the AppRole authentication method
     • Secret Id – Enter the secret ID to use with the AppRole authentication type.

   • UsernamePassword – If you select this option, make sure to also configure the following fields:

     • Username – Enter the username to use with UsernamePassword.
     • Password – Indicate the password to use with UsernamePassword authentication type.

   • Ldap – If you select this option, make sure to also configure the following fields:

     • Username – Specify the username to use with the LDAP authentication type.
     • Password – Indicate the password to use with LDAP authentication type.

   • Token – If you select this option, make sure to also configure the following field:

     • Token – Enter the token to use with the Token authentication type.
   • In the Secrets Engine field, select the secrets engine to use. Your options are:
     • KeyValueV1
     • KeyValueV2
     • ActiveDirectory
     • OpenLDAP
     • LDAP

5. In the Authentication Mount Path optional field, you can specify a custom mount path. You can mount the same authentication method with two different configurations, on two different paths.

6. In the Secrets Engine Mount Path field, provide the path of the secrets engine. If not supplied, it defaults to kv for KeyValueV1, kv-v2 for KeyValueV2 and ad for ActiveDirectory.
7. In the Data Path field, enter the path prefix to use for all stored secrets.
8. In the Namespace field, specify the namespace to use. Only available in HashiCorp Vault Enterprise.

9. For the (Ldap) Use Dynamic Credentials option, select True (dynamic) or False (static) to switch between dynamic and static credentials. The default option is False.

10. Select Create. Your new credential store is ready for use.

    
    

    

    
    

BeyondTrust

1. In the Type field, select one of the following options:

   • BeyondTrust Password Safe - Managed Accounts
   • BeyondTrust Password Safe - Team Passwords
2. In the Name field, specify the name of the BeyondTrust credential store.
3. In the BeyondTrust Host URL field, specify the URL of your secret server instance.
4. In the API Registration Key field, indicate the value of the API registration key from BeyondTrust.

5. In the API Run As Username field, specify the BeyondTrust username under which you want to execute the calls.

BeyondTrust Password Safe - Managed Accounts

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

1. Optionally, in the Default Managed System Name field, indicate the System Name managed by BeyondTrust Password Safe. This field serves as the fallback System Name if the Orchestrator asset's External Name field does not contain a System Name prefix.
2. In the System-Account Delimiter field, enter the delimiter used to split the System Name from the Account Name in the Orchestrator asset.
3. In the Managed Account Type field, select the type of account to be retrieved from BeyondTrust:
   • system - returns local accounts
   • domainlinked - returns domain accounts linked to systems
4. Select Create. Your new credential store is ready for use.

Note: The System Name must be specified either in the credential store in the format SystemName or in the Orchestrator asset's External Name field in the format SystemName/AccountName.

BeyondTrust Password Safe - Team Passwords

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

1. Optionally, in the Folder Path Prefix field, indicate a default folder path prefix. This will be added in front of all Orchestrator Asset values.

2. In the Folder / Account Delimiter field, enter the delimiter used to split the Path from the Title in the Orchestrator Asset.

3. Select Create. Your new credential store is ready for use.

   
   

   

   
   

Thycotic Secret Server

1. In the Type field, select Thycotic Secret Server.
2. In the Name field, type a name for the new credential store.
3. In the Secret Server URL field, specify the URL of your secret server instance.
4. In the Rule Name field, provide the client onboarding rule name.
5. Optionally, in the Rule Key field, indicate the key from the onboarding rule. While this step is optional, we recommend specifying the Rule Key for improved security.
6. In the Username Field field, specify the slug name of the Secret Template field that Orchestrator will pull the username from when retrieving an asset from Thycotic Secret Server.

7. In the Password Field field, indicate the slug name of the Secret Template field that Orchestrator will pull the password from when retrieving an asset from Thycotic Secret Server.

   Note: You can find the slug name of the Secret Template field in Admin > Secret Templates > Template > Fields.
   
   

   

   
   

When an asset or robot is created in Orchestrator, it is linked to a pre-existing secret using the External Name. In this case, that is the actual Secret ID from Thycotic Secret Server.

You can find the Secret ID in the route. In the following example, it value is 5.

AWS Secrets Manager

1. In the Type field, select AWS Secrets Manager or AWS Secrets Manager (read only).

   The choice between the read-only and the read-write version depends on your IAM policy permissions.

2. In the Name field, type a name for the new credential store.
3. In the Access Key field, add the access key ID available on the Security credentials tab of your AWS IAM user page.
4. In the Secret Key field, add the secret key ID that was provided to you when you created the AWS IAM user account.
5. In the Region field, add the region where you would like your secrets to be stored, as displayed in your AWS account.
   
   

   

   
   

   If you want to use AWS Secrets Manager (read only), you first need to create your asset or robot credentials in the AWS Secrets Manager.

Editing a credential store

Navigate to Stores (Tenant > Credentials > Stores) and from the More Actions menu of the desired store, select Edit. The Edit Credential Store dialog appears is displayed.

Note: The Orchestrator Database store does not have any editable properties.

Setting a default credential store

When using 2 or more credential stores, you have the ability to select which is the default store used for Robots and Assets. The same store may be used as the default for both, or you can select a different default store for each.

To select a default store, from the More Actions menu select Set as robots default store and/or Set as assets default store.

Note:

Changing the default store does not change an existing robot or asset configuration, it only controls what appears pre-selected in the Credential Stores drop-down when creating new robots or assets. Robots and assets always get their passwords from the store that was used when creating them. To change the credential store for a certain robot or asset, you must change it at the robot or asset level.

Deleting a credential store

To delete a credential store, select Remove from the More Actions menu of the desired store.

If the selected store is in use, a warning dialog will appear listing the number of robots and assets that will be affected. Click Delete to confirm the removal or Cancel to abort. Note that you must have at least one credential store active at all times. If only one is present, then the option to delete it does not appear.

Note: A credential store designated as default cannot be deleted. You must first select a different default store for the credential type.