Windows Discovery fails even when credential is Valid

[haruesgap]

Hi All, 

I'm looking for some wisdom or other ideas I've been not thinking of. 

I have a Windows service account with local admin rights as well for interactive logon active and I don't have issues while login directly to the host I want to discover. However from mid server I'm seeing this error:

Target is blacklisted. No valid credential found for type [Windows]

Although I've added an affinity entry and I'm seeing through Firewall traffic over port 135 it seems like discovery is not working properly. I've also noted that on the remote host I'm not seeing any login failure for the service account I'm using. and got this from powershell on the MID Server:

PS C:\Users\us-svcsnxxxxxx> gwmi win32_operatingsystem -computer 1x.xx.xx.xx -credential 'us\us-svcsnxxxxxxx'
gwmi : The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
At line:1 char:1
+ gwmi win32_operatingsystem -computer 10.43.20.3 -credential 'us\us-sv ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Get-WmiObject], COMException
+ FullyQualifiedErrorId : GetWMICOMException,Microsoft.PowerShell.Commands.GetWmiObjectCommand

RPC is enabled and working without issues. I'm running out of ideas. Anyone has faced this issue before?

[PavanBV]

Hi @haruesgap 

Please check this link.

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1116952

Thanks,
Pavan BV

[Selva Arun]

 Hi,

It sounds like you’ve already done a lot of troubleshooting, but let’s go through some additional steps to help resolve the issue. The error "Target is blacklisted. No valid credential found for type [Windows]" combined with "The RPC server is unavailable" suggests there might be a problem with WMI/RPC communication or credential validation between the MID Server and the target host.

Here’s a step-by-step guide to help you identify and fix the issue:

1. Check the Credentials

First, make sure the credentials you’re using are correct and have the necessary permissions:

• The service account should have local admin rights on the target server.
• Ensure interactive logon is enabled (you’ve already confirmed this).
• The account should also have WMI permissions to query the target system.

To test the credentials manually, you can use PowerShell on the MID Server:

gwmi win32_operatingsystem -computer <target_ip> -credential <domain\username> 

If this command fails with "The RPC server is unavailable", it confirms there’s a network or configuration issue.

2. Verify Network Connectivity

WMI relies on RPC for communication, so you need to ensure the required ports are open between the MID Server and the target server:

• Port 135: RPC Endpoint Mapper.
• Dynamic RPC Ports: By default, these are in the range 49152–65535 for modern Windows versions.

You can test connectivity using PowerShell:

Test-NetConnection -ComputerName <target_ip> -Port 135 

If dynamic ports are blocked, you can configure the target server to use a fixed port for WMI. Microsoft provides a guide on how to do this here:
https://learn.microsoft.com/en-us/windows/win32/wmisdk/setting-up-a-remote-wmi-connection

3. Check WMI and RPC Services

On the target server, make sure the required services are running:

• Windows Management Instrumentation (WMI):

Get-Service -Name winmgmt 

• Remote Procedure Call (RPC):

Get-Service -Name RpcSs 

If either service is stopped, restart it. For example:

Restart-Service -Name winmgmt 

4. Firewall and Antivirus

Firewalls or antivirus software can block WMI/RPC traffic. Ensure the following:

• The firewalls on the MID Server, target server, and network allow traffic on port 135 and the dynamic RPC ports.
• Work with your antivirus team to whitelist the MID Server and allow WMI/RPC traffic.

If you’re unsure about the dynamic ports, you can find more information on configuring RPC dynamic port allocation here:
https://learn.microsoft.com/en-us/windows/win32/rpc/rpc-dynamic-port-allocation

5. DNS and Kerberos

DNS and Kerberos issues can also cause problems. Here’s what to check:

• Use the nslookup command on the MID Server to verify forward and reverse DNS lookups for the target server:

nslookup <target_ip> 

The hostname returned should match the actual hostname of the target server.

• Check the event logs on the target server for Kerberos-related errors (e.g., Event ID 4). If you see an error like KRB_AP_ERR_MODIFIED, it usually means there’s a reverse lookup mismatch. Update the DNS records to fix this.

6. Discovery Configuration

• In ServiceNow, check the Discovery Credentials Affinity to ensure the correct credentials are mapped to the target host.
• If the target is blacklisted, you’ll need to remove it from the blacklist:
• Go to Discovery > Discovery Status > Blacklisted Items in ServiceNow.
• Find the target and remove it from the blacklist.

7. Debugging on the MID Server

• Enable verbose logging on the MID Server to capture more details about the failure. You can check the logs under MID Server > Logs in ServiceNow.
• Use a network monitoring tool like Wireshark to capture traffic while reproducing the issue. Look for blocked ports, Kerberos errors, or timeouts.

Example Case

In a similar case, the issue was caused by a DNS mismatch. Running nslookup <target_ip> on the MID Server and hostname on the target server revealed a mismatch. Updating the DNS records resolved the issue. Additionally, enabling the WMI firewall rules on the target server allowed the connection to succeed.

Helpful Resources

Here are some links to official documentation that might help you further:

1. Setting Up a Remote WMI Connection:
   https://learn.microsoft.com/en-us/windows/win32/wmisdk/setting-up-a-remote-wmi-connection
2. Configuring RPC Dynamic Port Allocation:
   https://learn.microsoft.com/en-us/windows/win32/rpc/rpc-dynamic-port-allocation
3. ServiceNow MID Server Documentation:
   https://docs.servicenow.com/bundle/utah-it-operations-management/page/product/mid-server/concept/c_M...

If you believe the solution provided has adequately addressed your query, could you please **mark it as 'Helpful'** and **'Accept it as a Solution'**? This will help other community members who might have the same question find the answer more easily.

Thank you for your consideration.

Selva Arun

[milkshakeduck]

We have the same issue - but its not consistent. Yokohama Patch 2

[Harish Bainsla]

Hi @haruesgap There are several reason for it you need to validate the following steps 

1. Credential Issues

2.Network/Firewall Issues

3.Remote WMI access may be blocked

> Login to mid server and run below command on powershell to check Credential 

Get-WmiObject -Class Win32_OperatingSystem -ComputerName <Target_IP> -Credential (Get-Credential)

Further you check below link for troubleshoot

MID Server - Troubleshooting WMI/Powershell issues and credentials - Support and Troubleshooting

And also Follow the steps which @Selva Arun told .

if my answer helps you mark helpful and accept solution