External credential storage

  • Release version: Yokohama
  • Updated January 30, 2025
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of External credential storage

    ServiceNow instances can store credentials used by Discovery, Orchestration, and Service Mapping in an external credential repository instead of directly within ServiceNow credentials records. This approach enhances security by keeping sensitive credential details outside the instance, while the MID Server retrieves and uses these credentials dynamically during operations. Currently, ServiceNow supports integration with CyberArk and BeyondTrust vaults as external credential storage solutions.

    Show full answer Show less

    How External Credential Storage Works

    • The instance maintains unique identifiers and types for each credential, along with credential affinities.
    • The MID Server downloads credential references from the ServiceNow discoverycredentials table, which include IDs pointing to the external vault.
    • When running Discovery or Orchestration probes, the MID Server passes credential information to a customer-provided Credential Resolver Java JAR.
    • The Credential Resolver interacts with the external vault (often via a vendor-supplied application on the MID Server machine) to retrieve actual credential details such as usernames and passwords.
    • Caching behavior varies by vendor; CyberArk’s out-of-box resolver caches credentials briefly in encrypted memory, and customers should consult third-party vendors for caching specifics.
    • The MID Server then executes probes using the resolved credentials, respecting existing credential affinity rules.

    Configuration and Management

    • The External Credential Storage plugin must be requested and activated to enable this functionality.
    • A system property, Enable External Credential Storage [com.snc.useexternalcredentials], controls enabling or disabling the feature. Disabling it automatically deactivates all external credentials; re-enabling requires manual reactivation of each credential record.
    • An External Credential Storage business rule updates credential record views to show Credential IDs and instructs the MID Server to refresh its credential cache when this property changes.
    • Configuration involves setting up the instance and MID Server to communicate with the chosen external vault (e.g., CyberArk), including deploying the Credential Resolver component.

    Logging and Troubleshooting

    The MID Server logs messages related to external credential storage operations. Errors during credential resolution are logged with the prefix: Problem with client's CredentialResolver, helping administrators identify and troubleshoot issues with vault integration.

    Key Benefits for ServiceNow Customers

    • Improved security by not storing sensitive credentials directly in the ServiceNow instance.
    • Seamless integration of Discovery, Orchestration, and Service Mapping with enterprise-grade credential vaults like CyberArk and BeyondTrust.
    • Support for OAuth 2.0 credentials stored in external vaults, enabling secure token management via the MID Server.
    • Flexible caching mechanisms to optimize performance while maintaining credential security.

    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 or BeyondTrust for external credential storage.

    External credential storage architecture

    Figure 1. 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. As each probe or pattern runs from Discovery or Orchestration jobs, the MID Server requests the credential by passing information such as credential ID, target IP address, and credential type to the Credential Resolver Java Jar file. The details about the correct credential object to retrieve from the vault are determined by the Credential Resolver.

      Many Credential Resolvers such CyberArk call an application supplied by the third-party vault vendor running on same machine as the MID Server. That application can often be configured to cache credentials and knows to update the cache when a credential changes in the vault, which is very important to avoid unnecessary network calls to the vault each time MID Server requests a credential. The Credential Resolver (using optional vendor application if present) makes a call to the vault to get the actual user name, password, etc.

      For Credential Resolvers supplied out-of-box (only CyberArk today), the MID Server only caches a credential for up to several seconds using encryption in MID Server process memory. This means the MID Server can make multiple requests to the Credential Resolver for the same credential even when discovering a single device. Contact third party vendors for information about caching implementations for other Credential Resolvers.

    3. 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 logging

    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 Enable External Credential Storage property:

    • Changes the view for the Credentials record list and form to the External Storage view. This view enables users 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’s 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 doesn’t reset the external credential records to active. You must reactivate each credential record manually.