Discovery credential configuration

[charang1210]

We are currently working on re-evaluating ServiceNow Discovery in our environment and need guidance on credential configuration and best practices.

In our setup:

• ServiceNow Discovery was previously used (around 2 years ago)

• Currently, we are using Discovery primarily for printer data via SNMP

• Most of our server and infrastructure data is being populated through Tanium (Service Graph Connector) into CMDB

We are now attempting to re-enable Discovery for servers, but during credential testing (CyberArk-managed service account), we are encountering authentication failures.

We would appreciate your guidance on the following:

• Best practices for using ServiceNow Discovery alongside Tanium integration

• Proper configuration of Discovery credentials (Windows/Linux) with CyberArk

• Troubleshooting steps for authentication failures during credential testing

• Recommendations on avoiding data conflicts or duplication between Tanium and Discovery

• Logs or debugging approaches (ECC Queue, MID Server logs) to further isolate the issue

inb the ecc queue logs no records found

Please let us know if any additional details or logs are required from our end.

Thanks for your support.

[amit_bt]

To re-enable ServiceNow Discovery while integrating with Tanium and CyberArk, focus on aligning your Identification and Reconciliation Engine (IRE) rules and ensuring the MID Server's local environment is correctly configured for external vaulting.

1. ServiceNow Discovery & Tanium Best Practices
Running both tools requires a "Source of Truth" strategy to avoid messy CMDB records.
Use Discovery for Depth, Tanium for Speed: Let Tanium's Service Graph Connector handle the high-speed population of basic server attributes. Use Discovery to enrich these records with deep dependency mapping (Service Mapping) and infrastructure details like SNMP for network gear.

Prioritize Data Sources: Configure Reconciliation Rules in the CI Class Manager. For example, set Tanium as the authoritative source for "Installed Software" and Discovery for "Network Adapters" or "Running Processes".
Avoid Duplication: Both tools use the ServiceNow IRE. Ensure Tanium is sending unique identifiers (like BIOS UUID or Serial Number) that match the Discovery Identification Rules to allow the system to update existing records rather than creating duplicates.

2. CyberArk Credential Configuration
For a successful CyberArk integration, the MID Server acts as the bridge.
JAR File Alignment: Ensure the javaPasswordSDK.jar in your MID Server’s agent/extlib folder exactly matches the version installed on the CyberArk AIM (Application Identity Manager) server. Version mismatches often cause silent authentication failures.
App-ID Permissions: Confirm the CyberArk App-ID (e.g., ServiceNow_MID_Server) has explicit permissions to the Safe where your server credentials are stored.
Credential Record Fields: In ServiceNow, your Credential record must have the External Credential Store flag checked and the Credential ID mapped correctly to the CyberArk "Name" attribute.

3. Troubleshooting Authentication Failures
If "Test Credential" is failing, follow this isolation path:
Test Outside ServiceNow: From the MID Server host, try to manually retrieve the password from CyberArk using the AIM CLI or API. If this fails, the issue is between the MID Server and the Vault.
Verify Target Access: Ensure the MID Server can reach the target server on required ports: 135/49152-65535 for Windows (WMI) or 22 for Linux (SSH).
Check Local MID Logs: If the ECC queue is empty, the MID Server may not even be picking up the job. Check the agent.log and wrapper.log for Connection Refused or Permission Denied errors during the credential fetch phase.

4. Isolating the "No ECC Queue Records" Issue
The absence of records in the ECC Queue typically points to a MID Server health issue rather than a credential issue:
MID Server Status: Navigate to MID Server > Servers and verify the status is Up and Validated.
Check the "Ready" State: If you recently ran a test, filter the ECC Queue for State=Ready. Records might be stuck if the MID Server is overloaded or offline.
Enable Debugging: Temporarily set the MID Server parameter mid.log.level to debug to see the detailed handshake between the MID, ServiceNow, and CyberArk.