Credentials for Local Agent-Based Inventory
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.)
- 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.
- 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, theLocalSystem
account is displayed asNT AUTHORITY\SYSTEM
) - Uses local OS authentication to take inventory; which means
that the
SQLNet.AUTHENTICATION_SERVICES
property must be set to(NTS)
in thesqlnet.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 runndtrack
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 asLocalSystem
(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). - Is the
- 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 theOracleInventoryUser
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 thesqlnet.ora
file located in the %ORACLE_HOME%/network/admin folder) - Is a member of
oinstall
(or equivalent group, granting execute permissions forsqlplus
) - 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 impersonatedDatabase connection is made as
sysdba
(and account must be a member of thedba
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 impersonatedDatabase 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 theLOGINAPPL
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:
- A target Oracle database instance is running on a UNIX platform, and
- This account (operating system user) was the one used to start the database instance, and
- The start-up specified an
ORACLE_HOME
path which included a symbolic link.
- 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 correctORACLE_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 theUserDefinedOracleHome
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.
- Must be
FlexNet Manager Suite (On-Premises)
2024 R1