Asset Management

Concepts

The Asset Management Module allows to keep an inventory of a company’s IT infrastructure. NetEye 4 integrates a solution to provide this functionality: the server part of the Open Source Software GLPI.

To install the Asset Management module, follow the guide for installing additional modules; the Asset menu item will then appear in the left side navigation menu.

GLPI

GLPI helps you planning and managing IT changes in an easy way, solving problems efficiently, automating business processes and gaining control over the IT infrastructure. GLPI provides advanced features for inventory, asset and mobile devices management.

The inventory feature of GLPI serves to collect assets from multiple devices in the monitored IT environment and list them in a inventory in GLPI. This functionality is granted by the GLPI Agents which send all the collected assets to the GLPI Server in the NetEye Master.

GLPI can be directly accessed from the NetEye GUI (within the Asset Management menu) using Single Sign On, if the logged user has permissions to access GLPI (see below). Upon the first access to GLPI from a user, that user will be created inside GLPI with GLPI permissions initialized.

The official, full documentation for GLPI is available directly from within its interface.

Note

If the user logs out from NetEye, its active GLPI session will be closed automatically and it will be redirected to the NetEye login page.

Multitenancy

With the entities being configured properly, GLPI supports multitenancy. The GLPI Server can be used by multiple tenants maintaining the confidentiality and integrity of the information: this feature is implemented by associating every NetEye Tenant to a dedicated GLPI Entity.

The general Multitenancy implementation, as described in the Fig. 242 is reached by having a GLPI Entity “Entity tenant A” associated to the NetEye “Tenant A”. Assets are sent by the GLPI Agent that belongs to the same Tenant authenticated through Basic auth and, if no rules are applied in GLPI, Assets are directly sent in the correct Entity.

Fig. 242 General GLPI Multitenancy implementation.

The possibility of adding custom rules in GLPI for associating defined assets to a specific entity remains valid: The following example displayed in Fig. 243 shows how, applying an inventory tag to a certain inventory and defining a GLPI rule that associates the tag to a specific sub-entity, GLPI rules are still applied for custom entity association.

Fig. 243 Rules are applied to associate an inventory tag with a specific GLPI Entity.

In order to maintain the separation of multiple Tenants, GLPI Agents are not allowed to import inventories to entities or sub-entities that don’t belong to the same Tenant. The Fig. 244 shows an example where a GLPI Agent tries to import an inventory with a tag that associates the inventory to another Tenant.

Fig. 244 The GLPI Agent is not allowed to upload inventories to entities for which is not associated to.

Configuration

GLPI

GLPI Permissions

Access to GLPI from the NetEye GUI is granted by permissions of a particular user role. In order to create a role with mentioned permissions, go to the Assetmanagement module in Configuration > Authentication > Roles, where you can set suitable permissions and restrictions. It is recommended to inherit role properties from the default role neteye_tenant_master. This existing role should never be modified since it has all the GLPI Entity configurations.

The profile and entities in GLPI of users must be mapped correctly in the NetEye (Configuration > Authentication > Roles) to persist across login/logout otherwise the GLPI profile and entity will be lost as soon as the user logged out from NetEye.

Each NetEye role corresponds to a unique combination of GLPI recursive profile/entity. For example, if a user belongs to more than one entity, or has different profile inside GLPI, he should belong to multiple NetEye roles.

Note that, if the GLPI user role will inherit the neteye_tenant_master role properties, the already configured GLPI Entity Root entity > master will be used without additional configuration steps.

It is possible to modify the GLPI entity of the parent role neteye_tenant_master in case we want to send assets directly to the GLPI Root entity or to another custom GLPI Entity. This can be done by using the parameter --custom-override-glpi-entity for the neteye tenant config modify command and should never be done by modifying the neteye_tenant_master role or the GLPI entity by hand. More information can be found in neteye tenant config create. However it is still not recommended to modify the GLPI entity for a better cooperation between NetEye and GLPI.

All entities and profiles must be created before users login for having a success permission synchronization. The only exceptions to this are the Root entity and the default GLPI profiles. If the profile/entities does not exist for the users in GLPI, then the mapping between NetEye and GLPI will not be successful.

Note that if you need to investigate on what happens during the permissions synchronization (e.g. for debugging purposes), you can have a look at the following logfile, in which are logged all the actions performed during the permissions synchronization:

/neteye/shared/glpi/data/_log/glpi-plugin-icingaweb2sso.log

GLPI Agent Configuration

In order to be able to perform inventory and collect assets with GLPI Agent, the following steps should be executed:

• Install GLPI Agent on the desired device following the official GLPI documentation.

• Ensure to have a NetEye user associated to a dedicated role for the GLPI Agent. The role used for the GLPI Agent must have the permission glpi/inventory enabled. If the recommended role neteye_tenant_master has been used as parent role, the GLPI Agent user is already present as neteye_glpi_agent_master. This NetEye profile is already configured correctly to work with the GLPI system and should not be modified.

• Configure the GLPI Agent to send assets to GLPI in NetEye using the following command:

glpi-agent -f --logger=stderr -s https://<user>:<password>@<your.neteye.hostname>/glpi/front/inventory.php

Where <user> is the NetEye user for the GLPI Agent (default neteye_glpi_agent_master) and <password> is the password of that user (default user password can be found in /root/.pwd_neteye_glpi_agent_master). More information about the glpi-agent command can be found in glpi-agent.

Multitenancy

If Multitenancy is used in GLPI, when creating a new NetEye Tenant as described in Configuration of Tenants, a dedicated GLPI Entity Root entity > 'New Tenant' will be created. All the users belonging to that Tenant should then be associated to the automatically created role neteye_tenant_<tenant_name> in order to have access to the Tenant’s entity in GLPI.

For every new tenant created, there will be a connected user named neteye_glpi_agent_<tenant_name> that can be used for the GLPI Agent. It can be configured as explained in the dedicated section in GLPI, using GLPI Agent user credentials found in /root/.pwd_<tenant_name>.

Warning

NetEye Roles, Users and GLPI Entities automatically created with the neteye tenant config create should never be modified to avoid permission issues or profile/entity mismatch between NetEye and GLPI.

Special Cases

There exist two special cases, with pre-defined triple recursive-profile-entity:

• NetEye users with Administrative Access

• NetEye users with Full Module Access for the Assetmanagement

Both cases correspond to users with Super-Admin recursive profile in the Root entity.

Note that for any reason you must not rename the GLPI Super-Admin profile and the Root entity.

GLPI Marketplace disabled

To guarantee the integrity of the NetEye ecosystem, we have decided to disable GLPI’s Marketplace feature. The users of GLPI will then be unable to use Marketplace.

Deprecated Solutions

OCS Inventory

Note

OCS Inventory is now deprecated. GLPI Agent should be used for inventory instead.

By deploying agents on each of the company’s devices, that send data to the server on NetEye, with the Asset Management Module it will be possible not only to keep the infrastructure’s inventory updated, but thanks to the REST API and the SNMP support it will be easy to interact with the devices and monitor them.

Currently, OCS inventory is integrated in the NeyEye GUI; during the setup process two users will be created:

• root is used to access the OCS Inventory’s GUI; here additional users can be created if necessary.

• agent is used to authenticate the OCS inventory agents, since basic authentication is required for OCS inventory agents to access the OCS inventory server. Note that these tasks can not be excuted as root. The corresponding password is contained in file /root/.pwd_ocsinventory_server_agent

OCS can be directly accessed from the NetEye GUI (within the Asset Management menu) using Single Sign On, if the logged user has permissions to access OCS (see below). Upon the first access to OCS from a user, that user will be created inside OCS with OCS permissions initialized.

Note

If the user logs out from NetEye, its active OCS session will be closed automatically and it will be redirected to the NetEye login page.

The official, full documentation for OCS inventory is available directly from within its interface.

Interaction between OCS and GLPI

During NetEye Asset group installation the GLPI’s plugin OCS Inventory NG will be automatically installed and set up.

This plugin allows the automatic synchronization between OCS Inventory NG and GLPI solutions. It replaces the OCS native mode of GLPI and use the plugin massocsimport functionality to provide better compatibility and scalability with OCS.

OCSInventory-NG import is performed using scripts (PHP or Shell) that automate synchronisation of computers. A graphical interface displays the list of defined scripts and all the related data.

Note

GLPI does not import new computers added to the infrastructure, therefore a script based on a systemd timer runs daily to ensure that the data about new computers is stored in GLPI.

During the plugin setup the default NetEye OCS Server will be automatically added to the plugin’s servers list. This server will be pre-configured with default synchronization settings and will point to the current OCS Inventory installation.

You can customize the plugin setting directly from within the GLPI’s GUI: Home ‣ Tools ‣ OCS Inventory NG in the main page of the plugin you can click on OCSNG server: NetEye OCS Server.

OCS Permissions

Users who wants to access the OCS from the NetEye GUI will need special permissions. To grant these permissions to users, you need to create a role (go under Configuration > Authentication > Roles) with a suitable permissions/restrictions (like e.g., profile) over the Assetmanagement module.

The OCS profile of users must be mapped correctly in the NetEye (Configuration > Authentication > Roles) to persist across login/logout.

Each NetEye role corresponds to a unique OCS profile. If a user belongs to more than one NetEye role which is assigned to more than one OCS Profile, she/he must be assigned to a single profile by following order:

• sadmin

• admin

• ladmin

• other profiles (alphabetical order)

All profiles must be manually created, before users login, for having a success permission synchronization. The only exceptions to this are the default OCS profiles. If the profile does not exist for the users in OCS, then he will redirect to the NetEye.

The OCS tags is a comma separated list of OCS computers tags that the users with this role are allowed to see. If left empty, which is the default, the user has access to all the tags. This restriction is considered only if the OCS Profile has the computers limitation enabled.

Note that if you need to investigate on what happens during the permissions synchronization (e.g. for debugging purposes), you can have a look at the following logfile, in which are logged all the actions performed during the process:

/neteye/shared/ocsinventory-ocsreports/log/logs/ocsinventory-ocsreports.log

Special Cases

There exist two special cases, with pre-defined profile:

• NetEye users with Administrative Access

• NetEye users with Full Module Access for the Assetmanagement

Both cases correspond to users with sadmin profile.

Note

For any reason, the user must not rename/remove the OCS sadmin profile and also, if he renamed the admin and ladmin profiles than they will be considered as normal profiles (alphabetical order)

Usage of SSL Certificates with OCSInventory NG

The security standards of NetEye disallow all insecure communication over public channels. This affects also the deployment of OCS Inventory Agents on all operating systems.

You can follow the Official Deployment Strategy and use the OCS Inventory NG Packager for deploying the Agents into your infrastructure. This section explains you how to find the server certificate needed by OCS Packager, which is also the certificate used by NetEye for all HTTPS communication and is usually signed by your company’s Certificate Authority.

You can find the correct path to your certificate in the file /etc/httpd/conf.d/ssl.conf and identify the line containing SSLCertificateFile (e.g. SSLCertificateFile /neteye/shared/httpd/conf/tls/certs/neteye.example.com.crt )

Since OCS Inventory Agents expect a cacert.pem file in PEM format, should you have a certificate in crt format, as in the above case, you can convert the file using the following command:

openssl x509 -in /neteye/shared/httpd/conf/tls/certs/neteye.example.com.crt -out cacert.pem

Replace the /neteye/shared/httpd/conf/tls/certs/neteye.example.com.crt file name with the one you found as SSLCertificateFile.