- Getting started
- Best practices
- Tenant
- About the Tenant Context
- Searching for Resources in a Tenant
- Managing Robots
- Connecting Robots to Orchestrator
- Storing Robot Credentials in CyberArk
- Storing Unattended Robot Passwords in Azure Key Vault (read only)
- Storing Unattended Robot Credentials in HashiCorp Vault (read only)
- Storing Unattended Robot Credentials in AWS Secrets Manager (read only)
- Deleting Disconnected and Unresponsive Unattended Sessions
- Robot Authentication
- Robot Authentication With Client Credentials
- Configuring automation capabilities
- Audit
- Integrating credential stores
- Managing credential stores
- Settings
- Cloud robots
- Folders Context
- Automations
- Processes
- Jobs
- Apps
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Resource Catalog Service
- Authentication
- Integrations
- Classic Robots
- Troubleshooting
Managing credential stores
Click Create - Orchestrator database stores do not have any configurable properties.
- In the Name field, type a name for the new credential store.
- 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.
- In the CyberArk Safe field, enter the safe name defined in the CyberArk® PVWA. See here for details.
- In the CyberArk Folder field, enter the location in which CyberArk® stores your credentials.
- In the Central Credential Provider URL field, enter the Central Credential Provider's address.
- 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.
-
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 followingcertutil
command to decode it in binary format:certutil -decode client_certificate_encoded.pfx client_certificate.pfx
- In the Client Certificate Password field, enter the password of the client certificate.
- 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. - The Allow OS User Authentication option is
only displayed when the value of the parameter
Plugins.SecureStores.CyberArkCCP.EnableOsUserAuthentication
is set totrue
. 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. - Select Create. Your new credential store
is ready for use.
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.
Key Vault credential stores use RBAC type authentication. After you've created a service principal, perform these steps:
-
In the Name field, type a name for the new credential store.
-
In the Key Vault Uri field, enter the address of your Azure Key Vault. This is
https://<vault_name>.vault.azure.net/
. -
In the Directory ID field, enter the directory ID found in the Azure portal.
-
In the Client Id field, enter the Application ID from your Azure AD App Registrations section where the Orchestrator app was registered.
-
In the Client Secret field, enter the secret needed to authenticate the client account entered in the previous step.
-
Click Create. Your new credential store is ready for use.
- In the Type field, select HashiCorp Vault or HashiCorp Vault (read-only) as your credential store.
- In the Name field, specify a name for the HashiCorp Vault credential store.
- In the Vault Uri field, indicate the URI to the HTTP API of HashiCorp Vault.
-
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
-
-
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.
- 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 andad
for ActiveDirectory. - In the Data Path field, enter the path prefix to use for all stored secrets.
- In the Namespace field, specify the namespace to use. Only available in HashiCorp Vault Enterprise.
-
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.
-
Select Create. Your new credential store is ready for use.
-
In the Type field, select one of the following options:
- BeyondTrust Password Safe - Managed Accounts
- BeyondTrust Password Safe - Team Passwords
- In the Name field, specify the name of the BeyondTrust credential store.
- In the BeyondTrust Host URL field, specify the URL of your secret server instance.
- In the API Registration Key field, indicate the value of the API registration key from BeyondTrust.
-
In the API Run As Username field, specify the BeyondTrust username under which you want to execute the calls.
If you chose BeyondTrust Password Safe - Managed Accounts, continue with the following steps:
- 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.
- In the System-Account Delimiter field, enter the delimiter used to split the System Name from the Account Name in the Orchestrator asset.
- 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
- Select Create. Your new credential store is ready for use.
SystemName
or in the Orchestrator asset's External Name field in the format SystemName/AccountName
.
If you chose BeyondTrust Password Safe - Team Passwords, continue with the following steps:
-
Optionally, in the Folder Path Prefix field, indicate a default folder path prefix. This will be added in front of all Orchestrator Asset values.
- In the Folder / Account Delimiter field, enter the delimiter used to split the Path from the Title in the Orchestrator Asset.
-
Select Create. Your new credential store is ready for use.
- In the Type field, select Thycotic Secret Server.
- In the Name field, type a name for the new credential store.
- In the Secret Server URL field, specify the URL of your secret server instance.
- In the Rule Name field, provide the client onboarding rule name.
- 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.
- 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.
-
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.
5
.
- 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.
- In the Name field, type a name for the new credential store.
- In the Access Key field, add the access key ID available on the Security credentials tab of your AWS IAM user page.
- In the Secret Key field, add the secret key ID that was provided to you when you created the AWS IAM user account.
- 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.
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.
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.
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.
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.
- Creating a credential store
- Orchestrator Database
- CyberArk CCP
- CyberArk Conjur Cloud (read-only)
- Azure Key Vault
- HashiCorp Vault
- BeyondTrust
- BeyondTrust Password Safe - Managed Accounts
- BeyondTrust Password Safe - Team Passwords
- Thycotic Secret Server
- AWS Secrets Manager
- Editing a credential store
- Setting a default credential store
- Deleting a credential store