Credentials for Local Agent-Based Inventory

FlexNet Manager Suite 2023 R1 (On-Premises)

The required accounts and their privilege levels vary across different types of operating system, and they are also different for the initial deployment (in the Adopted case) and subsequent steady-state operations. (The accounts you may need for deployment in the Agent third-party deployment case are left to your own management, and not described here.)

For the Windows platform:

• Adoption requires an account that:
  • May be either a local account on the target Windows device, or a Windows domain account
  • Has full access to the Windows Service Control Manager on that target Windows device (specifically, the account must have the SC_MANAGER_ALL_ACCESS access right)
  • Is registered in the secure Password Manager on the appropriate inventory beacon before running the discovery task that includes the adoption action.
  Once the FlexNet inventory agent is correctly installed (through the adoption process), this level of privilege is no longer required.
• Operation (after the FlexNet inventory agent is correctly installed) requires an account on the target device that:
  • Is the LocalSystem account on the target device (but for Oracle Database version 9i, see the following note)
  • Has read-only access to the Windows Service Control Manager (this allows discovery of Oracle services)
  • Is a member of the Windows local security group ora_dba (in which context, the LocalSystem account is displayed as NT AUTHORITY\SYSTEM)
  • Uses local OS authentication to take inventory; which means that the SQLNet.AUTHENTICATION_SERVICES property must be set to (NTS) in the sqlnet.ora file located in the %ORACLE_HOME%\network\admin directory (and be aware that, conversely, disabling OS authentication for your Oracle Database prevents the locally installed FlexNet inventory agent from gathering inventory from Oracle database instances). By default, Oracle disables OS authentication on Windows platforms.
  Note: Operation with Oracle Database 9i is an exceptional case. To collect Oracle 9i inventory on Windows, you must run ndtrack as a non-LocalSystem user account. This is only possible if you trigger the tracker with a custom command line, using your preferred scheduling tool (such as Microsoft Task Scheduler). This makes the local agent cases (whether the Adopted case or the Agent third-party deployment case) rather unsuitable for taking inventory for version 9i. In both these cases, the tracker runs under policy as LocalSystem (in which case it reports a failure to collect inventory from an Oracle 9i database instance); and if you run it again with a custom command line as a different account, you get inventory results. The combination of positive results gained with negative failure notifications is bound to produce confusion! For these reasons, if you have instances of Oracle Database 9i, it is better to consider the lightweight FlexNet Inventory Scanner, for which you can more easily manage your own command lines (see FlexNet Inventory Scanner Collection of Oracle Inventory); or even the Core deployment approach (for which see the Gathering FlexNet Inventory PDF).

For UNIX-like platforms:

• Adoption requires an account that:
  • Is local on the target device
  • Has ssh privileges
  • Can elevate to root-level privileges to complete the installation
  • Is registered in the secure Password Manager on the appropriate inventory beacon before the adoption process is run (and the additional details for elevation of account privileges with your preferred tool, such as sudo or priv, are also registered there).
• Operation (after the FlexNet inventory agent is correctly installed) requires an account on the target device that:
  • Must be root — otherwise local Oracle inventory collection is disabled
  • May impersonate other trusted accounts with lower privilege levels — as discussed in detail in the Common: Child Processes on UNIX-Like Platforms topic in the Gathering FlexNet Inventory PDF, along with coverage of the following preferences in the config.ini file that may affect the choice of account to impersonate:
    Tip: With neither of the following preferences specified, the default behavior is for FlexNet inventory agent to impersonate the account currently running the database instance, which is assumed to be a member of the dba group. This is the most straight-forward configuration, with no settings needed. If, instead, you intend to specify the OracleInventoryUser preference, it must be an exact match for any Oracle user name that:

    • Is also an operating system account
    • Has OS authentication enabled (and as well, OS authentication, which defaults to enabled for UNIX-like platforms, must not have been disabled using the SQLNet.AUTHENTICATION_SERVICES property in the sqlnet.ora file located in the %ORACLE_HOME%/network/admin folder)
    • Is a member of oinstall (or equivalent group, granting execute permissions for sqlplus)
    • Is either a current member of the dba group on the UNIX host server; or has adequate permissions for inventory gathering (as outlined in this table).

    OracleInventoryAsSysdba	OracleInventoryUser	Impersonation	Connection/Notes
    True (or omitted)	Configured	The account nominated in OracleInventoryUser is impersonated	Database connection is made as sysdba (and account must be a member of the dba group)
    True (or omitted)	Not configured	The account running the database instance is impersonated	Database connection is made as sysdba
    False	Configured	The account nominated in OracleInventoryUser is impersonated	Database connection is made as that same account (which in addition to the prerequisites above, must be configured with adequate read-only privileges as detailed in Appendix C: Oracle Tables and Views for Oracle Inventory Collection)
    False	Not configured	None	Oracle inventory collection does not proceed

    Note: On a UNIX-like platform, the tracker attempts to use setuid to impersonate the appropriate account to gather Oracle inventory. If you are using eTrust Access Control on this server, by default it does not permit this impersonation, and inventory gathering fails. The fix is to change the configuration of eTrust to include ndtrack in the LOGINAPPL class. For more information, see the eTrust Access Control Administation Guide (https://supportcontent.ca.com/cadocs/0/g007711e.pdf).
  • The impersonated account may need an environmental variable set within its login profile. This applies only in the case where:
    1. A target Oracle database instance is running on a UNIX platform, and
    2. This account (operating system user) was the one used to start the database instance, and
    3. The start-up specified an ORACLE_HOME path which included a symbolic link.
    This use of the symbolic link can hide the database instance from inventory collection by the installed tracker (ndtrack). Either of the following workarounds may be used to ensure that the local tracker can collect inventory from this database instance (and both workarounds may be implemented together without issue):
    • The account running the database instance (say OSUser4Oracle) may set an environment variable within its login profile specifying the ORACLE_HOME path (including the symbolic link) which was used to start the database instance. To test this setting, the following command should display the correct ORACLE_HOME path:

      su -OSUser4Oracle -c "echo \$ORACLE_HOME"

      Tip: If this environment variable is set for any account on the database server, it is applied to all database instances started by the same account on this server. Any mismatch between the (non-empty) environment variable, and the actual path used to start any of these database instances, prevents the collection of database inventory from the mismatched instance by the locally-installed inventory component (ndtrack). Conversely, you can prevent the environment variable option being used for all accounts on the target Oracle server by setting the UserDefinedOracleHome preference (details of this preference are included in Gathering FlexNet Inventory.
    • You can ensure that the Oracle home specified in the /etc/oratab file represents the ORACLE_HOME path used to start the database instance.