This site will be updating to the latest content for the next few hours and may be intermittently slow.

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

External credential storage architecture

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

External credential storage architecture

External credential storage requires a properly configured MID Server to retrieve the credentials from the external store.

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.


Figure 1. ServiceNow external credential storage architecture
ServiceNow external credential storage architecture