Thank you for your feedback.
Form temporarily unavailable. Please try again or contact docfeedback@servicenow.com to submit your comments.
Versions
  • Madrid
  • London
  • Kingston
  • Jakarta
  • Istanbul
  • Helsinki
  • Geneva
  • Store
Close

External credential storage

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

External credential storage

An instance can store credentials used by Discovery, Orchestration, and Service Mapping in an external credential repository rather than directly in a ServiceNow credentials record.

The instance maintains a unique identifier for each credential, the credential type (such as SSH, SNMP, or Windows), and any credential affinities. The MID Server obtains the credential identifier from the instance, and then uses a customer-provided JAR file to resolve the identifier from the repository into a usable credential. Currently, the ServiceNow® platform supports the use of the CyberArk vault for external credential storage.

External credential storage architecture

ServiceNow external credential storage architecture

Credential process flow

The MID Server retrieves credentials from an external store using this process:
  1. MID Server downloads credential objects from the ServiceNow Credentials [discovery_credentials] table that contain the corresponding credential ID from the target vault.
  2. MID Server checks to see if there are probes to execute from Discovery or Orchestration jobs.
  3. MID Server determines if the relevant credentials, such as SSH, Windows or SNMP, are available for the specified probe target. If not, the MID Server uses the Credential Resolver JAR to make a call to the vault to get the actual user name and password. The details about the correct credential object to retrieve from the vault are determined by the Credential Resolver JAR file. Information such as credential ID, target IP address, or credential type are available to the JAR file. If a credential has been retrieved from a previous probe, the credential is cached and is not retrieved again, unless the MID Server is restarted or specifically directed to flush the credential cache.
  4. MID Server executes the probe with the appropriate credential.
Note: Credential affinity still applies. The mechanism remains the same, since the only real difference from the MID Server's perspective is that the real credential details (user name and password) come from the third party vault.

External credential storage log

The MID Server posts log messages about external credential storage.

If the repository encounters an error while attempting to resolve a credentials request, the MID Server posts log messages with this prefix: Problem with client's CredentialResolver:

Components installed with External Credential Storage

Business rule

The External Credential Storage business rule performs the following tasks when an administrator makes any change to the external credential storage property:

  • Changes the view for the Credentials record list and form to the External Storage view. This view enables users to to see the Credential ID column in the list.
  • Instructs the MID Server to refresh its credentials cache in preparation for a change in the way credentials are obtained.
Property

A property called Enable External Credential Storage [com.snc.use_external_credentials] enables or disables the External Credential Storage plugin after it is activated. The property is located in Discovery Definition > Properties and Orchestration > MID Server Properties, and is enabled when you activate the plugin.

If you disable external credential storage with the system property, the system automatically sets all the external credentials to inactive in the instance. If you re-enable the feature with this property, the system does not reset the external credential records to active. You must reactivate each credential record manually.

Feedback