Troubleshooting Classification Phase Failure

The classification phase is the first phase where Discover tries to use credentials specified in Discovery Credentials. Problems here are often associated with using the incorrect user account or incorrect user account and password combination. These also include:

  • SSH authentication errors in Linux/Unix
  • Bad Powershell configurations on Window

The below example shows that during the classification phase on this Linux/Unix device, we received an error: “SSH authentication or connection failure” which stopped Discovery. This message means that the MID Server was not able to log onto the target machine so the classification probe could not get any information from it.

The device history shows that it did find device 10.11.15.151 and saw it as “active” but could not log into it. This could be due to issues with network connectivity or incorrect credentials issues. In this case, since Shazzam was able to communicate with the machine but was unable to log on, the issue most likely may be caused by bad credentials.

The ECC Queue shows that Discovery first launched a Shazam probe (output), received information from that probe (input), then it launched a Classification probe (output), then finally it received information back from that probe (input).

If you look at the classification probe input record, you can see the result showing error “SSH authentication or connection failure”.

In Windows, authentication failure looks similar to a Linux authentication failure except that Windows uses Powershell to login. The first error circled in red basically means that none of the Windows Credentials created, can be used to authenticate to the Windows target machine. The second error circled in blue basically shows Discovery trying to use the MID Server’s “service” account to login into the target credential but that too failed.

The MID Server’s service account is the account used to start/stop the MID Server services on the MID Server. If you want, you can disable Discovery from using the service account from being used as a fallback so that PowerShell only uses credentials, specified in the ServiceNow instance.

To disable Discovery from using the MID Server service account, on the ServiceNow instance, go to the MID Server record, go to Configuration Parameters, and click NEW to create a new Parameter:

For the Parameter Name, select “mid.powershell.local_miid_service_credential_fallback and set the value to “false”.

If that parameter is configured, rather than seeing the Discovery log errors shown above, you instead will see the following error: Authentication failure(s) with available WIndows credentials from the instance. This means Discovery tried all Windows credentials specified in the instance but all credentials failed. It also no longer attempted to log on with the MID Server service’s account.

By looking at the classification phase’s input record, you can find what went wrong during the classification phase. Below, you can see two errors: “Authentication failure with the local MID Server service credential” and “Failed to access Target System”.

When you see Errors in the input record of the classification probe Payload XML file showing “authentication failure” or “failed to access target system”, the cause is typically a failure in the authentication phase. The solution is to provide the proper credentials in the ServiceNow instance or in the Log On tab of the MID Server Services Properties page.