Troubleshooting

To collect logs for ServiceNow Mid Server instances, follow these steps:

  1. Check the Logs file of MID Server in case of failures. Logs are stored at <Mid Server installation path> / agent/log/.

  2. Select the wrapper.log file to be shared.

    Ensure the log level is configured to 4 to capture detailed logs, especially when validating credentials.

  3. Review the wrapper.log file for any debug messages or errors related to the issue.

Known Issues

Credential Resolver Configuration – Secret Name Encoding

When using a Secret Name as the ServiceNow Credential ID, ensure the name is properly URL encoded. Secret names containing spaces or special characters must be encoded (e.g., My%20Secret instead of My Secret).

Alternatively, set the parameter search_secret_by_name=false and use the Secret ID instead. This avoids issues with URL encoding.

Active Directory Account – Domain Requirement

The credential resolver does not automatically retrieve the Domain field from the Active Directory Account template.

To ensure successful authentication, add the domain as a prefix to the Username field in the secret (e.g., DOMAIN\username).

Active Directory Secret Creation Template Issue

When creating a secret for an Active Directory account, always select the Windows Account template. Ensure that you enter the username in the correct format: domain\username.

This format works for both ServiceNow and Secret Server.

If the AD template is specifically required, ensure the Delinea Credential Resolver is configured so the username includes the domain; otherwise, ServiceNow validation may succeed, but Secret Server RPC/heartbeat will fail.

*Delinea includes both default templates (e.g., Windows, MySQL, SSH) and custom templates for specialized use cases). To learn more about secret templates, go here Built-in Secret Templates.

Certificate Errors

If you see failures in validating credentials, review the MID Server's agent log. If you find errors referring to PKIX path failures, the SSL certificate for Secret Server needs to be imported into the Java Keystore for the MID Server agent, see the Adding SSL Certificate to MidServer for more details.

PKIX Errors Example Log:

alt

If the Credential Resolver is not working, use the following solutions.

  • External Credential storage ServiceNow instance plugin: After adding External Credential storage plugins to ServiceNow instance, sometimes user can't see the checkbox for External Credential Store plugin on credentials page (ServiceNow instance > Discovery > Credentials). To solve this problem, wait and refresh at regular intervals.

  • Authentication fails: Check the following if authentication fails.

    • Correct the credentials of a Secret in Secret Server.
    • The user in configuration file should have a View permission under Secret > Sharing in Secret Server.
    • Check the permissions of the Secret Server user that was used in the configuration file. The user should have an Application Account with at least View Launcher Password permission.

    • Check the Secret Server ss_url , ss_auth_str parameters in the config.xml file.

    • Verify the credentials you entered when running the DelineaMidServerUIUtility-1.0.jar file.

  • Timeout Exception: If network issues occur, a user might experience a timeout exception. If this happens, check the network and restart the MID Server and validate it again.

  • Invalid target specified: During the test if the user receives an invalid target specified message, do the following:

    • Check the hostname or the IP address of a Secret in Secret Server.
    • Use the IP address entered while testing the credential. Make sure it is correct and the machine credential is in the Secret Server template.

  • Version Mismatch: If the user has a version mismatch, upgrade MID Server because the ServiceNow instance was upgraded to a higher version.

  • Unable to decrypt the credential: The encrypted string copied from the command prompt to config.xml failed to decrypt.

    • Run the DelineaMidServerUIUtility-1.0.jar file on the same server as the Mid Server.

    • Ensure tags are copied correctly.

  • Unable to run the DelineaMidServerSetupUtility JAR file:

    Use "Java -version" command to ensure that Java 11 or higher is installed on your machine.

  •  Debugging Tips:
    • If the plugin is not working, check the MID Server Logs file. Check to see that all configurations of config.xml file are correct.
    • Check the user permission in Secret Server for the user which is configured in MID Server config.xml file (MID Server path/agent/config.xml).
    • Check all the Secret details in the Secret, (for example, passwords and machine details).

     

Grant File Token Expiration

The following FAQ addresses common questions about grant file behavior and OAuth token lifecycle when using Grant File Mode with Secret Server.

Why does the grant file time out?

The grant file contains an OAuth access token issued by Secret Server. When that token reaches its configured expiration time, the MID Server can no longer authenticate using the stored grant file, and the file must be regenerated with a fresh token. This is token expiration — not a session timeout — and is governed by the token lifetime settings configured in Secret Server.

Is an active session left open between requests?

No. The MID Server credential resolver is stateless. Each credential request runs independently; no persistent connection or session is maintained between the MID Server and Secret Server.

Does ServiceNow release or invalidate the token after use?

There is no active session for ServiceNow to release. Once issued, the token remains valid until its expiration time is reached and is reused by subsequent credential requests until it expires.

Can the token be revoked before it expires?

Token revocation is supported in Secret Server and can be performed manually by an administrator. However, revocation is not automatically triggered after each ServiceNow discovery process or credential lookup. Under normal operation, token expiration manages the full token lifecycle.

Why does the first discovery process succeed but later probes fail?

ServiceNow Discovery runs multiple probes as part of a single discovery job, and each probe requests credentials independently. If the token in the grant file expires between probe executions, later probes will fail to authenticate. This can appear as though the grant file timed out mid-process, but the root cause is token expiration occurring between individual probe requests. To resolve this, regenerate the grant file to obtain a fresh token, and consider increasing the token lifetime in Secret Server to exceed the expected duration of a full discovery job.

Automatic token renewal is not currently part of the grant file behavior. The grant file must be manually regenerated, or token generation must be scheduled externally, when the token expires.