Saturday, October 15, 2005

SMS Network Discovery

I think one of the biggest shortcomings with SMS right now is its inability to do true network discovery - walk a network, through routers and return a list of systems both in SMS and those not. I think there was a step back made as well in SMS 20003 where the DHCP option is disabled when going to Advanced Security. Obviously there are technical reasons for this change (mainly security related with account authentication) but I think more effort could have been made in this area to come up with a viable alternative.

One of the problems with Network Discovery is that not many people in the Product Group understand every bit of it from a code level any longer. In fact I wouldn't be surprised if it was removed from the next version of SMS. I did want to take a moment to publish some things that I have investigated that aren't documented but I've been told are fine to publicly disclose. Note that this is legacy SMS 2.0 stuff that is still true with SMS 2003 is Standard Security but I'm not sure how much of it changes when going to Advanced other than dropping everything DHCP specific:

OIDs that are access:SnmpObjectIdentifier objIdSysDescr ("1.3.6.1.2.1.1.1.0");SnmpObjectIdentifier objIdSysObjId ("1.3.6.1.2.1.1.2.0");SnmpObjectIdentifier objIpForwarding ("1.3.6.1.2.1.4.1.0");SnmpObjectIdentifier dataObjId = data.GetInstance(); SnmpObjectIdentifier objIdIpNetToMediaPhyAddress("1.3.6.1.2.1.4.22.1.2");SnmpObjectIdentifier objIdIfPhysAddress("1.3.6.1.2.1.2.2.1.6");SnmpObjectIdentifier objIdIpRouteNextHop("1.3.6.1.2.1.4.21.1.7");SnmpObjectIdentifier objIdIpAdEntNetMask("1.3.6.1.2.1.4.20.1.3");SnmpObjectIdentifier objIdIpAdEntIfIndex("1.3.6.1.2.1.4.20.1.2");SnmpObjectIdentifier objIdIfType ("1.3.6.1.2.1.2.2.1.3");

Only MIB2 is accessed.

SNMP is v2 and its used to query hosts in three different phases to acquire a lot of information from the host (query if it is a router, get its ARP cache, and other values). It uses MIB II, RFC1213. Specifically the system, interfaces, interface table, nettomedia tableand routing table.

OSPF is used to detect subnets that are announced in the Hello packets. RIP is used pretty much the same way (announcement only).
The extra information to determine different devices and OS types is collected using only the NetServerGetInfo API call with the discovered device name. I don't know how the call interrogates the devices or whether it sends requests to non-Lanman devices. The device types are reported as various sorts of Windows if recognized, otherwise as "Unknown".

An ICMP ping is done agains discovered devices having IP addresses.
The DNS name is queried using the sockets API gethostbyaddr.
From what I've been told, Network Discovery extracts all information using only the published network APIs like the ones mentioned above. No DCOM communication seems to be used other than the exception of some Active Directory awareness.

Here is the simplified process flow:
1. Discovery enumerates networks and devices inside the defined scopes and queues them for processing.2. Various processing modules (dns resolver, icmp echo, nt browser, ...) process the devices, and for any device that matches the module defined scope, they extract more info and add it to the device's attribute list.3. At the end of the processing queue each processed device record generates a DDR containing its collected data. The DDRs are written to the Discovery Data Manager inbox.

Comments: Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?