Common: Child Processes on Windows Platforms

IT Asset Management (Cloud)

In all of the Adopted case, the Agent third-party deployment case, and the Zero-footprint case, the tracker always runs as LocalSystem, because elevated privileges are required to complete several aspects of inventory gathering. In the Core deployment case or the FlexNet Inventory Scanner case, it is possible to run the tracker under a different account, but best practice is to run it with administrator privileges, or you may lose inventory functionality.

Note: On Microsoft Windows, the tracker does not prevent invocation by an account that has lesser privileges; but you would then need to ensure that such an account had all the required access rights for the kinds of inventory you expected to gather on a target device. Since this is highly dependent on your environment, this approach is unsupported.

Since the tracker always runs with elevated privileges, it is important that it only acts in place of accounts that are known and trusted in your environment. In many cases, the commands or services are already running as LocalSystem on your Oracle server(s), so there is no effective change when the tracker does the same. But with Oracle Database 12c, or with IBM MQ (previously WebSphere MQ), it is possible that a service account has been used. To ensure that only actions by accounts that are trusted are also run by the tracker, it relies on details found in the Windows registry and in Windows Service Control Manager (SCM), both of which can only be modified by a system administrator.

In summary:

• Commands in safe system paths (not writable by other users) are run as LocalSystem.
• Commands found within paths listed in the %PATH% environment variable for the LocalSystem user are run as LocalSystem.
  Note: This makes it important that, as is normal secure practice, you do not allow any unsecured directories to be included in the %PATH% environment variable for the LocalSystem user.
• Other necessary commands and utilities are run as LocalSystem only if:
  • They are normally executed by accounts trusted in your Windows SCM configuration, or
  • They are saved in paths recorded in Oracle keys or IBM MQ keys in the Windows registry.
  • Specifically for java.exe commands, the PerformOracleJavaAuditScan preference is enabled and the java.exe being considered is digitally signed.

The table of child processes on Windows is organized in alphabetical order of the executables invoked by the tracker.

Tip: All child processes are invoked in hidden mode.

Executable	Path	Notes
cmd	C:\Windows\System32	Command line: C:\Windows\System32\cmd.exe script Purpose: Runs the named script that has been delivered within InventorySettings.xml (these scripts may be updated through the Application Recognition Library). These scripts provide specialized inventory-gathering steps for use with Oracle products. They include the Oracle GLAS scripts required for preparing an Oracle audit report. Invoked using: The account running the ndtrack executable (default: LocalSystem).
db2licm.exe	Path(s) for IBM Db2 found in the Windows registry HKEY_LOCAL_MACHINE\ SOFTWARE\IBM\DB2\ InstalledCopies	Command line: \successfulPath\bin\db2licm.exe -l / -g Purpose: Reports inventory of the IBM Db2 Database (including its product identifier) and its optional add-ons, including the available license information. Invoked using: The account running the ndtrack executable (normally LocalSystem). With the parameters shown above, IBM Db2 on Microsoft Windows allows this command without an elevated account; although with certain additional parameters, an elevated account becomes necessary.
db2ilist.exe	Path(s) found in the Windows registry for IBM Db2.	Command line: \successfulPath\bin\db2ilist.exe Purpose: Lists all the database instances running in the context where db2ilist is executed (normally, instances from the same database installation that provides the db2ilistexecutable). Invoked using: The account running the ndtrack executable (normally LocalSystem, although IBM Db2 does not require elevated privileges for this command on Windows).
dspmq	Path(s) found in the Windows registry for IBM MQ.	Command line: \successfulPath\dspmq -o all Purpose: Reports as installation evidence the name (as ProductName) and active/inactive state (as EditionName, blank for active) of the queue managers on the system. Used by the Application Recognition Library to recognize IBM MQ (previously known as WebSphere MQ Manager). Invoked using: The account running the ndtrack executable (default: LocalSystem).
dspmqver	Path(s) found in the Windows registry for IBM MQ.	Command line: \successfulPath\dspmqver Purpose: Collect the IBM (or WebSphere) MQ version and build information for inclusion in inventory. Invoked using: The account running the ndtrack executable (default: LocalSystem).
java	Path(s) found in the file system scan in which java was identified.	Command line: java -version java -fullversion java -XshowSettings -version Purpose: Determines the Java product name, version information, and publisher. Further notes: Only executed if the PerformOracleJavaAuditScan preference is enabled and the java.exe being considered is digitally signed.
lsnrctl	%ORACLE_HOME%\bin	Command line: %ORACLE_HOME%\bin\lsnrctl Purpose: Invokes the Oracle Listener Control utility against a running listener to gather its network port address and the services (local and remote database instances) to which it provides access. Invoked using: The account running the ndtrack executable (default: LocalSystem).
nbtstat	%PATH%	Command line: \%PATH%\nbtstat -A IPAddr Purpose: Returns the local NetBIOS name table for the computer at the nominated IP address, as well as the MAC address of the adapter card connecting it to the network. This data is used in discovery. Invoked using: The account running the ndtrack executable (default: LocalSystem).
powershell	On 64-bit systems: %SystemRoot%\system32\ WindowsPowerShell\v1.0and on 32-bit systems: %SystemRoot%\SysWOW64\ WindowsPowerShell\v1.0	Command line: \platformPath\powershell.exe Purpose: Runs the named script that has been delivered within InventorySettings.xml (these scripts may be updated through the Application Recognition Library). These scripts provide specialized inventory-gathering steps for use with Oracle products. They include the Oracle GLAS scripts required for preparing an Oracle audit report. Invoked using: The account running the ndtrack executable (default: LocalSystem).
sqlplus	%ORACLE_HOME%\bin	Command line: %ORACLE_HOME%\bin\sqlplus "/ as sysdba" Purpose: Perform queries against running Oracle database instances to gather inventory on the Oracle Database product. (For ways that the tracker identifies %ORACLE_HOME%, see the topic How Agent-Based Collection of Oracle Inventory Works in the IT Asset Management System Reference PDF.) This Oracle utility is invoked by a script delivered within InventorySettings.xml (described in the entry for cmd). Invoked using: The account running the ndtrack.exe executable (default: LocalSystem). The account running ndtrack must be a member of the ora_dba security group for the target Oracle Database (where the LocalSystem account is displayed as NT_AUTHORITY\SYSTEM; and if this account is missing, it must be entered as SYSTEM). Tip: From Oracle Database 12c, there is a distinct ora_dba group for each separate %ORACLE_HOME%. Note: This approach means that the tracker can collect inventory only from running database instances. Instances that are discovered, but are not running at inventory time, are reported in the task status: navigate to the discovered device properties, select the Status tab, and expand the Oracle database inventory heading.
vxlicrep	File path extracted from %VCS_ROOT%.	Command line: \successfulPath\VRTSsfmh\bin\vxlicrep.exe Purpose: Creates installation evidence used by the Application Recognition Library to recognize installations of Symantec. Invoked using: The account running the ndtrack executable (default: LocalSystem).