Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.

Introduction to credentials

Log in to subscribe to topics and get notified when content changes.

Introduction to credentials

Several applications require credentials to access resources during discovery, including Discovery, Orchestration, Service Mapping, and Cloud Management.

Credential types

The following credential types are provided:
Credential type Description Supports Test Credential option
Applicative Credentials The credentials to explore the applications on a device or computer. Patterns often need applicative credentials. No
AWS Credentials The Amazon Web Services (AWS) master account, access key ID, and secret access key.
Note: You cannot test AWS credentials through the Test
Azure Service Principal The Azure service principals required for an Azure subscription. No
Basic Authentication Credentials A user name and password. No
CIM Credentials The user name and password required to access a CIMOM - Common Information Model Object Manager (CIM) server, which obtains information about VMware ESX servers. No
Cloud Management Credential Credentials that Orchestration uses to access cloud resources. No
JDBC Credentials A user name and password to access a Java Database Connectivity (JDBC) connection. Yes
JMS Credentials A user name and password to access to a Java Message Service (JMS). Yes
SNMP Community Credentials (Password Only) The community string to access devices via SNMP. Yes
SNMPv3 Credentials The user name and keys required to access devices on your SNMP v3 network. Yes
SSH Credentials The user name and password to access Linux and Unix devices. Yes
SSH Private Key Credentials The private key credentials to access Linux and Unix devices.

SSH private key credentials are recommended over SSH password credentials for security reasons.

VMware Credentials Credentials to access vCenter resources. These credentials are required for any work that is performed on vCenter, such as cloning a virtual machine. Yes
Windows Credentials The user name and password required to access Windows computers. Several permission requirements must be met to use Windows credentials. Yes

How MID Servers use credentials

By default, Windows MID Servers use the login credentials of the MID Server service on the host machine to discover Windows devices in the network. You should configure these service credentials so that they have at least local administrator privileges. For Linux and UNIX machines and network devices, the MID Server uses the SSH and SNMP credentials configured in the instance in Discovery > Credentials.

MID Servers that Orchestration uses must have access to the necessary credentials to execute commands on computers in the network as specified by the Workflow activities. Orchestration can use the same SSH and SNMP credentials as Discovery, but has two additional credentials designed for specific Workflow activities: Windows (for PowerShell) and VMware.

Encryption and decryption

The platform stores credentials in an encrypted field on the Credentials [discovery_credentials] table. Once they are entered, they cannot be viewed.

When credentials are requested by the MID Server, the platform decrypts the credentials using the following process:
  1. The credentials are decrypted on the instance with the password2 fixed key.
  2. The credentials are re-encrypted on the instance with the MID Server's public key.
  3. The credentials are encrypted on the load balancer with SSL.
  4. The credentials are decrypted on the MID Server with SSL.
  5. The credentials are decrypted on the MID Server with the MID Server's private key.
Note: The platform does not have separate encryption keys for multi-tenant instances.

Credential order

Credentials can be assigned an order value in the Credentials Form, which forces the application to try all the credentials at their disposal in a certain sequence. If you do not specify an order value, the application tries the credentials in the Credentials [discovery_credential] table randomly, until it finds one that works, such as when Orchestration attempts to run a command on an SSH server (such as a Linux or UNIX machine), or when Discovery attempts to query an SNMP device (such as a printer, router, or UPS).

After identifying the credentials for a device, Discovery and Orchestration create an affinity between the credentials and the device using the Credential Affinity [dscy_credentials_affinity] table. All subsequent discoveries or Orchestration activities attempt to match the credentials in this table with a device for which an affinity exists. If credentials for a device change, Discovery and Orchestration try all available credentials again until they create a new affinity.
Note: If Orchestration and Discovery are installed, and credential tagging is enabled, multiple affinities can exist. In this case, the platform looks up credentials for each affinity and inserts the credential for the affinity with the lowest order into the probe.
Ordering credentials is useful in the following situations:
  • The credentials table contains many credentials, with some used more frequently than others. For example, if the table contains 150 SSH credentials, and 5 of those are used to log into 90% of the devices, it is good practice to configure those five with low order numbers, which places them at the top of the execution list. Discovery and Orchestration will work faster if they try these common credentials first. After the first successful connection, the system knows which credentials to use the next time for each device.
  • The system has aggressive login security. For example, if the Solaris database servers in the network only allow three failed login attempts before they lock out the MID Server, configure the database credentials with a low order value.

Credential tagging

Credential tagging allows workflow creators to assign individual credentials to any activity in an Orchestration workflow or assign different credentials to each occurrence of the same activity type in an Orchestration workflow. Credential tagging also works with credential affinities.

External credential stores

If you do not want credentials stored in your instance, you can use external credential repositories. External credential stores save the credentials in an external site that your instance can access. Only CyberArk is supported.

Credential synchronization with MID Servers

Each MID server on your network synchronizes with your instance keeps what is essentially a copy of every credential that you create. This synchronization is done to speed up the reading of credentials when applications like Discovery or Service Mapping need to access multiple devices on the network. The MID Servers synch when they find a credentials_reload job in the ECC Queue. The reload job instructs the MID Server to make a SOAP call to the instance to get the entire list of credentials, including all the field values, in the Credentials [discovery_credentials] table.

The SOAP response that your instance sends to each MID Server also includes custom fields that you added to any credential form that you customized. If you added reference fields, the data in the referenced table is also sent as part of the SOAP response.