1
0
-1

I have several devices on my network that, when scanned by Open-Audit, they show up as a switch instead of a computer.  The only thing these computers have in common is they have a SmartBoard connected to them.  Attached is a screen shot of what Open-Audit sees

 

When I manually scan and show the "debug" it shows the results below.  I notice it says WMI is false but I have checked the PC and WMI is enabled.

LOG   - Discovery submitted for 10.2.7.10
DEBUG - Command Executed: /usr/local/open-audit/other/discover_subnet.sh subnet_range=10.2.7.10 url=http://10.1.3.82/open-audit/index.php/discovery/process_subnet submit_online=n echo_output=y create_file=n debugging=0 subnet_timestamp="2015-05-12 13:31:28" 2>&1
DEBUG - Return Value: 0
DEBUG - Command Output:
Array
(
    [0] => <devices>
    [1] => 	<device>
    [2] => 		<subnet_range>10.2.7.10</subnet_range>
    [3] => 		<man_ip_address>10.2.7.10</man_ip_address>
    [4] => 		<mac_address></mac_address>
    [5] => 		<manufacturer><![CDATA[]]></manufacturer>
    [6] => 		<type><![CDATA[unknown]]></type>
    [7] => 		<os_group><![CDATA[Windows]]></os_group>
    [8] => 		<os_family><![CDATA[Windows 2008]]></os_family>
    [9] => 		<os_name><![CDATA[Microsoft Windows 7|Phone|Vista|2008]]></os_name>
    [10] => 		<description><![CDATA[general purpose|phone]]></description>
    [11] => 		<org_id></org_id>
    [12] => 		<snmp_status>true</snmp_status>
    [13] => 		<ssh_status>false</ssh_status>
    [14] => 		<wmi_status>false</wmi_status>
    [15] => 		<p80_status>false</p80_status>
    [16] => 		<p443_status>false</p443_status>
    [17] => 		<tel_status>false</tel_status>
    [18] => 		<subnet_timestamp>2015-05-12 13:31:28</subnet_timestamp>
    [19] => 	</device><device><subnet_range>10.2.7.10</subnet_range><subnet_timestamp>2015-05-12 13:31:28</subnet_timestamp><complete>y</complete></device></devices>
)
DEBUG - Starting process_subnet.
DEBUG - Back to input page
DEBUG - Front Page
DEBUG - ----------------------------------------------------
SimpleXMLElement Object
(
    [subnet_range] => 10.2.7.10
    [man_ip_address] => 10.2.7.10
    [mac_address] => SimpleXMLElement Object
        (
        )

    [manufacturer] => SimpleXMLElement Object
        (
        )

    [type] => SimpleXMLElement Object
        (
        )

    [os_group] => SimpleXMLElement Object
        (
        )

    [os_family] => SimpleXMLElement Object
        (
        )

    [os_name] => SimpleXMLElement Object
        (
        )

    [description] => SimpleXMLElement Object
        (
        )

    [org_id] => SimpleXMLElement Object
        (
        )

    [snmp_status] => true
    [ssh_status] => false
    [wmi_status] => false
    [p80_status] => false
    [p443_status] => false
    [tel_status] => false
    [subnet_timestamp] => 2015-05-12 13:31:28
    [show_output] => 1
)
LOG   - Start processing 10.2.7.10
DEBUG - existing system key found for System ID: 15713.
LOG   - WMI Status is false on 10.2.7.10
LOG   - SNMP Status is true on 10.2.7.10
LOG   - SSH Status is false on 10.2.7.10
LOG   - Attempting SNMP discovery on 10.2.7.10
LOG   - SNMPv2 connected to 10.2.7.10 (System ID 15713) using supplied credentials
LOG   - SNMPv2 SysObjectId for 10.2.7.10 (System ID 15713) is 1.3.6.1.4.1.29485.1.1.2
LOG   - SNMPv2 manufacturer for 10.2.7.10 (System ID 15713) is: TeleSuite Corporation
LOG   - SNMPv2 could not load the snmp helper for 29485 when scanning 10.2.7.10 (System ID 15713)
LOG   - SNMPv2 model for 10.2.7.10 (System ID 15713) is: TeleSuite Corporation(using Entity MIB)
LOG   - SNMPv2 model for 10.2.7.10 (System ID 15713) is: (using Resources MIB)
LOG   - SNMPv2 model for 10.2.7.10 (System ID 15713) is unknown
LOG   - SNMPv2 serial for 10.2.7.10 (System ID 15713) is unknown
LOG   - SNMPv2 MAC Address for 10.2.7.10 (System ID 15713) is 78:45:c4:32:50:47
LOG   - SNMPv2 has determined a type of switch for 10.2.7.10 (System ID 15713)
LOG   - SNMPv2 scan of 10.2.7.10 (System ID 15713) completed
DEBUG - Command Executed: which ipmitool 2>&1
DEBUG - Return Value: 0
DEBUG - Command Output:
Array
(
    [0] => /usr/bin/ipmitool
)
LOG   - Ipmitools detected when discovering 10.2.7.10
DEBUG - Command Executed: ipmitool -H 10.2.7.10 -U  -P  lan print 2>/dev/null | grep "^MAC Address" | cut -d":" -f2- | cut -d" " -f2
DEBUG - Return Value: 0
DEBUG - Command Output:
Array
(
)
LOG   - SNMP update for 10.2.7.10 (System ID 15713)
LOG   - SNMP credential update for 10.2.7.10 (System ID 15713)
DEBUG - System ID 15713
LOG   - Completed processing 10.2.7.10 (System ID 15713)
DEBUG - ----------------------------------------------------
SimpleXMLElement Object
(
    [subnet_range] => 10.2.7.10
    [subnet_timestamp] => 2015-05-12 13:31:28
    [complete] => y
)
LOG   - Deleting credential set for 10.2.7.10 submitted on 2015-05-12 13:31:28
    CommentAdd your comment...

    2 answers

    1.  
      1
      0
      -1

      Okay but I have the Windows Firewall disabled on other machines and WMI is true and I get a proper audit.  It looks to me like it has something to do with the SmartBoard connected to the computer.  That is the common thread for all of the computers that show up as a switch instead of a computer.

      On this machine I do have Windows Firewall disabled and the services show WMI is running.  Our network uses Symantec as the firewall, is there anything in the Symantec server that needs to be set to allow Open-Audit to get its info?

      1. Mark Unwin

        If Open-AudIT says WMI = false then "something" is stopping it. From what you have described I would bet on Symantec. I have no knowledge of configuring this client side application - sorry. You could try disabling the Symantec firewall completely to run a test Discovery, then re-enabling it again.

      CommentAdd your comment...
    2.  
      1
      0
      -1

      Yep - WMI = false is the answer. This means the Open-AudIT server cannot detect the WMI port being open on the target. Open-AudIT is relying on Nmap to tell it what the device is (which is essentially a guess).

      This might be due to the target running a firewall or something in between the target and the server blocking that port.

      We have a wiki page on the Target Requirements that explains what to check. It is here - Target Client Configuration.

        CommentAdd your comment...