Thanks Mark for your answer.
So, apparently the match is on:
397 | 2020-10-20 10:44:48 | m_device | match | HIT on serial + type. | success | Serial: 8P73GW2, type: computer, SystemID : 2 |
That serial is the laptop running Windows 10, while the server (running as a VM) shows:
C:\Users\Administrator>wmic bios get serialnumber
SerialNumber
Not sure what's going on
Thanks!
Try the below on the server at a dos prompt.
wmic csproduct get IdentifyingNumber
The serial is taken from win32_ComputerSystemProduct.IdentifyingNumber.
Hi Mark:
That field comes empty too on the server:
PS C:\Users\Administrator> wmic csproduct get IdentifyingNumber
IdentifyingNumber
PS C:\Users\Administrator>
The code that checks serial + type check like this -
if (strtolower($match->match_serial_type) === 'y' &&
empty($details->id) &&
! empty($details->serial) &&
! empty($details->type) &&
! in_array($details->serial, $invalid_strings)) {
The list of invalid strings is a single entry in the array of: 'To be filled by O.E.M.'
I am unsure how it can possibly match on an empty serial.
If you run a discovery on the server, then check the discovery logs, what do you see?
So, I ran the discovery on the server while already existing on the database,a and the serial comes thru empty, as expected:
580 | 2020-10-20 18:31:36 | wmi_helper | wmi_command | Attempting to execute command using winexe-static-2 | success | ["IdentifyingNumber","",""] |
And the discovery is finding existing host by matching Hostname + UUID:
590 | 2020-10-20 18:32:12 | m_device | match | HIT hostname + uuid | success | Hostname: ansydwdc01, UUID: 103F0EC5-90C3-4743-B063-71ADF360BDA8, SystemID : 6 |
Need to run audit on laptop and repeat the discovery and see what happens.
I'll post it when done.
Thanks for your help
Running the audit script on the laptop overrides the virtual server again, due to match on serial + type:
680 | 2020-10-21 09:13:44 | m_device | match | HIT on serial + type. | success | Serial: 8P73GW2, type: computer, SystemID : 6 |
After that, I ran the discovery again on the server followed by the audit script (on the server too) and now the two devices are finally registered.
So, it seems that it's a non-empty serial what it's overriding an empty serial number, and not the other way around, according to what happened in these last tests.
Thx
Juan.
Looks like the two devices have the same UUID.
I would delete both, then rerun the discoveries and see what happens.
Alright, I think I finally solved the mystery.
The laptop ( a DELL with a vEthernet Bridge interface for the mini-USB to connect to the dock station) comes with a MAC address that the server also has assigned to the NMAP Loopback interface created by the NMAP package, installed there.
That's where the match is happening.
After removing both assets and starting over, that's what I saw.
What are the odds?
This should explain matching. If it doesn't please do ask questions.
You can see in a device's discovery log what it matched on.
Hi there:
I've got two windows machines that are overwriting each other every time the audit script runs and submitted to the Open-Audit Server.
The UUID that I see on the database, once the script completes for each machine, is different but the machines are overriding each other.
There are also many other values that are different in both machines, starting from the operating system (Windows Server 2016 in one case and Windows 10 the other).
I'm running Open-Audit 3.5.0, community edition, installed on CentOS 7.
Any clues?
Thanks!