The discovery service identifies systems in the network and obtains relevant information from them as quickly as possible and with the lowest impact, using a variety of different tools and techniques to communicate.

Discovery process terminology

In BMC Atrium Discovery, a Linux-based appliance controls the Windows-based discovery process. This process follows the model of communication where one device (the master) has unidirectional control over one or more other devices (known as proxies). This unidirectional control relationship is required because a Linux-based application cannot discover the quality of information required from a Windows system, so it requires that the Windows system perform those tasks itself. Consequently, both master and proxy are used to describe the Windows discovery process throughout the documentation. For additional terms and definitions, see the Glossary.

Discovery service basics

Discovery occurs using a combination of the central UNIX discovery service and a Windows proxy. The Windows proxy is required because the methods that are used to access Windows hosts are available only from Windows systems. When the Discovery Engine determines that the target host runs a Windows-based operating system, it sends a discovery request to a Windows proxy.

A typical organization may use firewalls to partition its networks and protect it from unauthorized access. BMC Atrium Discovery offers a central discovery service, allowing any network systems on the same network to be discovered. For systems beyond firewalls to be discovered, new firewall rules must be created to enable BMC Atrium Discovery to detect those devices or to connect to additional discovery appliances that can consolidate discovery data to the central discovery service.

For each IP address, the discovery service performs of the following tasks (although it may skip some steps in the process):

1. Checks if the IP address is marked as one to avoid. If so, no further discovery attempt is made.
2. Checks for cached data for that IP address.
3. Checks for a previously successful login (login, Windows proxies, and SNMP) method and uses that to log on and run discovery commands.
4. Performs an access method port scan. If there is no response, no further discovery is attempted.
   From here, the remaining steps are attempted in sequence and, when one is successful, the results are passed to OS Heuristics.
5. Attempts to login (using shell first, and then using Windows proxy if shell is unsuccessful) and run discovery commands if suitable credentials or an Active Directory Windows proxy are available.
6. Performs an SNMP get on the SysObjectId.
7. Performs an SNMP get on the SysDesc OID.
8. Checks for fallback information (a previously successful SNMP discovery).
9. Connects using telnet to read the banner.
10. Connects to the z/OS Host Server port.
11. Performs an HTTP HEAD request on the host.
12. Connects using ftp to read the banner.
13. Matches open ports (IP fingerprint) to predict a class of operating system.
    The discovery service is likely to be able to identify the operating system and version without requiring all of the steps described previously. After it has discovered sufficient information, the discovery service stops working on that IP address and moves on to the next address. If no additinal IPs are queued, it idles.

Any device that discovery cannot log into is identified only by the results obtained from reverse DNS lookup, telnet, SNMP requests, and IP fingerprinting (where enabled). Hosts and mainframe computer nodes are created only after a successful login. Network device nodes are created after a successful SNMP access.

UTF-8 Data BMC Atrium Discovery stores and suppoprtall character data as UTF-8, but does not support direct discovery of data outside the basic ASCII character set. If such data is discovered, BMC Atrium Discovery is unable to map it to UTF-8 and invalid characters are introduced into the discovery data. Windows proxies do attempt some conversion of this data.

UNIX discovery

The BMC Atrium Discovery appliance is UNIX-based and uses the discovery service to determine the type and version of the operating system. The discovery service on the appliance attempts to use ssh (or if desired telnet/rlogin) to access the host, performs connectivity checks on known ports, and attempts to log on with stored credentials and run discovery commands.

Windows discovery

Windows discovery is performed using Windows proxies. This is application software that runs on a number of Windows hosts on the network. For more information, see Windows discovery.