CyberArk credential storage integration

  • Release version: Yokohama
  • Updated January 30, 2025
  • 4 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 CyberArk credential storage integration

    The CyberArk credential storage integration for ServiceNow Yokohama release enables ServiceNow Orchestration, Discovery, and Service Mapping to operate without storing credentials directly on the ServiceNow instance. Instead, credentials are centrally managed, securely stored, and accessed through the CyberArk vault, enhancing security and compliance with internal and regulatory requirements.

    Show full answer Show less

    CyberArk Application Identity Management (AIM) eliminates embedded passwords in applications and scripts by managing privileged account credentials within the CyberArk vault. This approach supports periodic password rotation and activity monitoring for privileged identities both on-premise and in the cloud.

    Key Features

    • Credential Resolution: The ServiceNow MID Server retrieves credential identifiers, types, and target IPs from the instance and uses CyberArk to resolve these into usable credentials. It also supports hostname and FQDN lookups including reverse DNS.
    • Plugin Requirement: The integration requires the ServiceNow External Credential Storage plugin to be activated.
    • Installation: The MID Server and CyberArk AIM/API client must be installed on the same machine. Supported CyberArk Credential Providers version is 12.0.1 and later.
    • Business Rule & System Property: An External Credential Storage business rule manages credential views and refreshes MID Server caches on changes. The system property Enable External Credential Storage controls activation of the integration and manages credential record status accordingly.
    • Supported Credential Types: Includes GCP, Azure, CIM, JMS, SNMP, SSH (key pair and private key), VMware, Windows, and Basic Auth among others. Note that GCP integration requires modifying the external credential storage jar.
    • Network Protocol Support: Credentials stored in CyberArk support ServiceNow AI Platform features and workflows involving SOAP, REST, JDBC, SSH, PowerShell, SFTP, and JMS protocols.
    • Credential Lookup Logic: For Windows accounts, the MID Server first matches credential IDs in CyberArk. If multiple credentials share an IP address, a configuration parameter (ext.cred.typespecifier) can enforce matching by both credential type and IP to avoid lookup conflicts.
    • Library Upgrades: The CyberArk client library can be upgraded via the MID Server by registering new jar files and cleaning up old versions through the eccagent table, ensuring secure configuration parameters are applied.

    Practical Considerations for ServiceNow Customers

    • Activating the External Credential Storage plugin and enabling the related system property is essential to use CyberArk integration.
    • Ensure the MID Server and CyberArk AIM/API client reside on the same machine to enable credential resolution.
    • Administrators should be aware that disabling external credential storage sets all external credentials inactive, requiring manual reactivation upon re-enabling.
    • The integration supports a broad range of credential types and network protocols commonly used in ServiceNow orchestration and discovery workflows.
    • Careful configuration of MID Server parameters can prevent credential lookup conflicts in environments where multiple credential types share IP addresses.
    • Upgrading the CyberArk library requires specific steps to maintain secure configurations and proper MID Server operation.

    Next Steps

    Customers should follow the detailed CyberArk and ServiceNow configuration procedures to implement this integration, referencing CyberArk documentation as needed. Proper setup ensures credential security, compliance, and seamless orchestration and discovery operations without storing sensitive passwords on the ServiceNow instance.

    The MID Server integration with the CyberArk vault enables ServiceNow® Orchestration, ServiceNow® Discovery, and ServiceNow® Service Mapping to run without storing any credentials on the instance.

    Introduction to CyberArk

    CyberArk Application Identity Management (AIM) product uses the Privileged Account Security solution to eliminate the need to store application passwords embedded in applications, scripts or configuration files, and allows these highly sensitive passwords to be centrally stored, logged, and managed within the CyberArk vault. This approach enables organizations to comply with internal and regulatory requirements of periodic password replacement and to monitor activities associated with all types of privileged identities, whether on-premise or in the cloud.

    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, credential type, and IP address from the instance, and then uses the CyberArk vault to resolve these elements into a usable credential. The credential resolver can also look up the hostname, fqdn, and use reverse DNS lookup to get fqdn.

    The CyberArk integration requires the ServiceNow® External Credential Storage plugin, which is available in System Definitions > Plugins. The MID Server and CyberArk AIM/API client must be installed on the same machine. CyberArk Application Access Manager (AAM) Credential Providers version 12.0.1 and later is supported.

    Installed with CyberArk

    • 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 see the Credential ID column in the list.
      • Instructs the MID Server to refresh its non-external credentials cache in preparation for a change in the way that credentials are obtained.
    • System 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. This property is located in Discovery Definition > Properties and Orchestration > MID Server Properties, and is enabled when you activate the plugin.
      Note:
      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.

    Supported credential types

    The CyberArk integration supports these ServiceNow credential types:
    • GCP
    • Azure
    • CIM
    • JMS
    • SNMP forum
    • SNMPv3
    • Basic Auth
    • SSH Key Pair
    • SSH Private Key (with key, pass phrase, and password)
    • VMware
    • Windows
    • Applicative Credentials
    Note:
    To use CyberArk integration with the GCP credential type, you must modify the external credential storage jar. For details see ServiceNow GCP Credential Resolver using CyberArk.

    ServiceNow AI Platform features that use these network protocols also support the use of credentials stored on a CyberArk vault.

    Table 1. Credentials supported by network protocol
    Network protocol ServiceNow® Workflow Studio support Orchestration support
    SOAP SOAP Step Create a SOAP web service activity with basic authentication overrides
    REST REST Step Create a REST web service activity with basic authentication overrides
    JDBC JDBC Step JDBC activity
    SSH SSH Step SSH activity
    PowerShell PowerShell Step PowerShell activity
    SFTP SFTP Step SFTP activity
    JMS JMS activity
    Important:
    You cannot manage credentials stored on a CyberArk vault and a custom external credential storage system using the same MID Server. The MID Server and CyberArk AIM/API client must be installed on the same machine.

    CyberArk architecture

    Figure 1. CyberArk storage architecture
    CyberArk storage architecture.
    Note:
    CyberArk uses the base system mid.jar file for resolving credentials.

    How the MID Server handles Windows accounts

    Credential lookup initially attempts to match the specified credential ID to an existing value in the CyberArk vault Name field. If a match is found, that credential is returned. If no match is found, the credential lookup attempts to find a match using the IP address. If the IP address lookup matches more than one credential, such as Windows and Tomcat on the same server, the lookup fails. To avoid this issue, set the ext.cred.type_specifier parameter in the MID Server config.xml file to true to force CyberArk to return credentials that match both the credential type and the IP address. For example, if an IP address is shared by both Windows and Tomcat, a credential type of Windows returns the Windows credential only.

    Upgrade the CyberArk library

    You can upgrade the CyberArk library if a secured configuration parameter is needed.

    Check the following configuration parameter in the config.xml: <parameter name="mid.secure_config.provider" value="com.service_now.mid.services.config.CyberArkSecuredConfigProvider"/>

    Perform the following steps to perform the upgrade if a secured config parameter provider is configured.
    1. Rename the CyberArk client version to JavaPasswordSDK_MajorVersion_minorVersion_patchNum.jar.
    2. Create a new jar entry in the ecc_agent table where the rename jar can be attached. This new entry downloads to the MID Server. This step results in two jar (Passworsdk.jar and JavaPasswordSDK _12_X_X.jar).
    3. Delete old ecc_agent entry from instance. This step deletes Passworsdk.jar from the MID Server, and the JavaPasswordSDK _12_X_X.jar remains in the system.