CI Lookup Rule - MAC Address Rule Not Matching to Parent CI

[SnowedIn]

Hi guys,

TLDR: Mac Address CI Lookup Rule returning Network Adapter as CI to populate VIT's when it is meant to be the parent CI.

I have integrated Vulnerability Response with Tenable and am having some issues with the CI Lookup Roles - specifically the Mac Address rule. It is the first rule that runs which is good as the MAC Address is the most unique identifier.

I have looked at the following documentation (CI Lookup Rules for identifying configuration items from Vulnerability Response third-party vulnerab...).

Here I noticed the note: "To avoid matching on low-level networking elements, if a matched CI is one of dscy_switchport, cmdb_ci_network_adapter, cmdb_ci_nic, or cmdb_ci_ip_address, the parent CI is returned."

One of my problems at the moment is VIT's are being created with the Network Adapter as the CI instead of the parent CI (which could be a Virtual Machine for example). I've reviewed the OOTB CI Lookup Rule for the Mac Address matching and it does return the parent ("cdmb_ci") on the Network Adapter CI but still, the Discovered Item record and all the VIT's are still being set as the Network Adapter (although on the Discovered Item, the parent CI does appear in 'Other Matched CIs').

Has anyone had this before and have a solution? The Network Adapter doesn't make sense to be the CI for the VIT so I want to change it to the parent CI and all debugging and logging I have done suggests the script is returning the correct parent CI sys_id, but the matched CI is still the Network Adapter.

Since this is OOTB functionality (and even states for Network Adapters the parent CI is returned) I am confused.

Can provide more info if needed.

Thanks

[Amit Gujarathi]

HI @SnowedIn ,
I trust you are doing great.

Based on the documentation you mentioned (CI Lookup Rules for identifying configuration items from Vulnerability Response third-party vulnerabilities), it states that if a matched CI is one of the following: dscy_switchport, cmdb_ci_network_adapter, cmdb_ci_nic, or cmdb_ci_ip_address, the parent CI should be returned to avoid matching on low-level networking elements.

You mentioned that you reviewed the Out-of-the-Box (OOTB) CI Lookup Rule for the Mac Address and confirmed that it does return the parent CI ("cdmb_ci") for the Network Adapter CI. However, despite this, the Discovered Item record and all the VITs still have the Network Adapter set as the CI. Although the parent CI appears in the 'Other Matched CIs' field of the Discovered Item, it does not reflect as the CI for the VITs.

If I understand correctly, you are looking for a solution to change the CI for the VITs from the Network Adapter to the correct parent CI. It's puzzling because the script you've debugged and logged seems to be returning the correct parent CI sys_id, but the matched CI remains the Network Adapter.

Given that this is a built-in functionality (and even indicates that the parent CI should be returned for Network Adapters), it is indeed confusing

[SnowedIn]

Yes, what you have said is correct. That is the problem I am faced with, I have done extensive troubleshooting and it does seem to be returning the correct parent CI sys_id but still the CI for the VIT and Discovered Item is being set to the Network Adapter. Since it is OOTB I expected it to work.

[MB6]

We had run into this exact problem. The issue was that there were duplicate network adapters, both had the same IP and mac address but only one had the parent configuration item while other had the configuration item field as blank. The OOTB script was matching both but selecting one without the parent. That's probably the behavior you are seeing as well. The resolution was to delete the duplicate network adapter, the one without the parent CI and let the sync happen again. Also, you have to look directly in the network adapter table "cmdb_ci_network_adapter_list.do", and check for the duplicates. 

[SnowedIn]

Thank you, I will take a look. I know there are some duplicates but I think I was testing on one that didn't have that problem. I will double check.