Skip to main content
Matrix42 Self-Service Help Center

Product Hardening (Security)

Goal

The goal of product hardening is to reduce the possibilities of exploiting vulnerabilities in order to be better protected against attacks.

For example, vulnerabilities are exploited for identity theft, resulting in the imminent blackmail or industrial espionage. For this reason, appropriate protective measures should be activated with the following objectives:

  • Reduction of the possibilities for exploiting vulnerabilities
  • Minimization of the possible methods of attack
  • Limiting the tools available to an attacker after a successful attack
  • Minimizing the privileges available to an attacker after a successful attack
  • Increasing the probability of detection

General recommendations

Matrix42 recommends that some basic things be considered when configuring and operating Empirum. Some additional concepts for securing general IT operational security (e.g. Microsoft ESAE and shielding the network with firewalls and similar) are not part of this document.

Users and System Accounts

If possible, use dedicated Active Directory accounts or local accounts for each task. Accounts used on the servers for services, synchronization tasks or administration should not be used as accounts for agent access to the server or domain join during the operating system installation.

  • Assign as few rights as possible and as many rights as necessary.

Basically, Empirum can be configured so that no user and password information need to be stored on a managed computer. This is made possible using certificate-based authentication or computer domain account login when accessing the Empirum server from the client/depot.

Agent Configuration

The UEM Agent Windows allows the use of the so called software push. This method is an ad-hock alternative to the standard pull based installation command. It uses an open UDP-Port 10043 which allows the Empirum master server to send installation commands directly to the computer. As this operation currently uses no authentication we recommend to switch off the "Allow software push" setting in the Agent Template configuration as unwanted installation commands can be send to perform installations from the Empirum software library or reboot the computer.

Using passwords in Empirum

Matrix42 offers customers the possibility to use their own variables with the type password in software packages to be able to use them during execution. Although these are stored in unreadable form, they can be output in plain text again to be used in installation scripts. This cannot be prevented by the system. In principle, normal users do not have access to the control files containing the encrypted data, but local administrators can gain access to them. Therefore, it is recommended to use these script passwords only where no alternatives (Single Sign on, Matrix42 MyWorkspace) are available.

In addition to the passwords that can be used in scripts, Empirum uses an AES256-based encryption variant for the internal components (depot server synchronization with EmpSync, agents). No component is provided for this encryption variant that can convert them back to plain text. Since this variant is based on a shared secret procedure, it cannot be excluded that decryption may also be possible with local access.

Matrix42 recommends using this for all Empirum Agent configurations and depot synchronization where the use of certificates or computer accounts is not possible.

When configuring the "Subdepot" and "Subdepot Webservices Configuration" packages, the use of variables is necessary because various PowerShell scripts are used during installation. The relevant INI files in which this information is stored are not copied or kept on managed computers, but are only available to these servers.

Storage of the configuration files

The configuration files where passwords are stored are protected by NTFS permissions against unprivileged access to the managed computers.

Computername.ini - Computer and user-specific file containing configuration information for installation packages Only the custom file is saved locally.

AgentTemplate.xml - General configuration files of the Empirum Software Management Agent and the OS installation All configuration files are stored locally. This file contains no passwords when using certificate-based or computer account authentication.

The Interpreter Setup.exe

The interpreter "Setup.exe" is used for the processing of Empirum scripts by the Empirum Agent. In the [Encryption] section of the standard Setup.inf, there is the possibility to decrypt Empirum's own encryptions (Setup, Sync) in order to be able to pass them to commands during script processing.

This means that such a password (Setup, Sync) can be issued in plain text by a simple ECHO command.
Encryption methods affected: Setup, Sync

Configuration of the Master Server

The standard Empirum installation is designed to be directly functional in every customer constellation.

To ensure operation that meets increased security requirements, it is recommended that you carry out some configuration measures. In addition, depending on the customer's situation, for example if computers from the Internet are to directly access Empirum servers in their own network, further measures are necessary.

ODBC Connections

Use the newer Microsoft ODBC drivers for SQL Server, which are directly supported. These support Kerberos only and TLS.

Securing the Windows Services on the Empirum Server

Managed service accounts are specific user accounts in the Active Directory that are suitable for use as user accounts of on-premises services. It is not administrators who manage the passwords of these accounts, but the Active Directory automatically takes over this task. Administrators do not need to know or change the password.

https://blogs.technet.microsoft.com/askds/2009/09/10/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting/

https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview#BKMK_APP

Securing the Empirum shares

Matrix42 provides "Best Practice" guidelines for secure operation in an AD environment in the online help. These can be manually configured according to the table, or automatically configured using the Empirum Subdepot package. For this purpose, the variable SET_NTFS_RIGHTS must be set to 1 on the master server before execution and to 0 again afterwards (otherwise this would be repeated every time the package is installed). On Empirum Depot servers, this is done automatically during the first installation.

Additionally, it is possible to remove the NTFS-Rights Read and Execute for the group Everyone on the Confgurator\User folder. Please make sure that only UEM Agent based methods are used for installing and running Inventory and Personal Backup. For example, running Inventory via Configurator$\User\InvScan_XML.bat as a user will not work. It is planned to use the more secure rights structure by default in an upcoming Empirum version.

NULL Session Shares are not required anymore and can be removed. New installations will not create them on the Empirum Server.

Using https with a valid certificate

As an alternative to the use of SMB, it is possible to operate software distribution, operating system installation, patch management, inventory and also the synchronization of Empirum Depots via https. This eliminates the need for end users or the agent to access the Windows shares of the depots. The agent also checks the authenticity of the certificate to prevent so-called "man-in-the-middle" attacks. In addition, it is possible to authenticate the computers using a certificate (see below).

Using Packet Validation

Software packages are checked for integrity before execution - by means of a hash. This validation ensures that a software package has not been deliberately or accidentally manipulated throughout the entire transport chain. This setting is strongly recommended.

Using the digital signature of metadata

In order to be able to guarantee the origin of the packages beyond any doubt, the relevant metafiles are provided with a digital signature. This setting is recommended.

For more information, refer to the online help.

Empirum Depot Synchronization

Up to Empirum version 20.0 the program EmpSync is used for depot synchronization. The configuration of the used user account is done via variables. The used user needs appropriate read and write permissions on the Empirum Master Server according to the authorization specifications in the help. The user should only be used for this purpose. The passwords are stored with AES256 encryption to prevent unveiling with on-board equipment.

Starting with Empirum version 20.0, it is possible to use the depot synchronization integrated in the UEM Agent. In this case, the settings configured for the UEM Agent to access the Empirum Master Server apply. This enables the use of password less authentication and is therefore recommended.

Database Access on active Depots

Active depots with PXE/WOL services can be operated in an online and offline variant. When using the online method the information to access the database is locally stored on the depot server in the computer.ini (password variable) and registry. When using the offline method no database access information is stored on the depot server as the communication is performed via files and the already established file synchronization mechanism of the depot server. Matrix42 recommends to use the offline depot method for a higher secure operation.

LDAP sync

The LDAP sync service supports secure connection via port 636 to Active Directory out-of-the-box. No special settings for the service are required.

Email dispatch

Email transmission for configured alarms is always via a secure connection (TLS) with user authentication.

Access of managed computers to Empirum servers

The Empirum Agent (Windows UEM Agent or Advanced Agent and macOS Agent) works locally with a system account. Several variants are offered for logging into the Empirum Server (Master or Depot):

  • User Account: We recommend using a normal domain user without additional AD group permissions. An interactive login does not have to be allowed. The Agent template contains an AES256 encrypted password. Please note the hint on password encryption.
  • Certificate-based authentication: Very secure. Dummy users and passwords are stored in the Agent template. This is currently only supported for https communication.
  • Computer domain account: Very secure. Dummy users and passwords are stored in the Agent template. This is currently only supported for SMB communication.

Agent Login with User and Password

Use the internal Empirum encryption (AES256) when configuring the agent user via the SUBDEPOT variables PASSWORD_1 - _3.

When using DHCP options, it is possible to use only the server name and not to specify a user and password. In this case, the authentication of the failure server stored in the Agent Template is used. If you use DHCP options with user and password, we recommend using the AES256 variant.

Matrix42 recommends the use of certificate-based authentication, or the Computer Domain Account. In these cases, no usable passwords are stored in the Agent Template.
For more information, refer to the online help.

Agent Login with Certificate-based Authentication

The alternative use of https with certificate-based authentication allows you to work without user accounts in the configuration files on the computers. The Empirum Agent (Windows and macOS) uses a computer certificate for authentication. There are no encrypted Agent user passwords locally in the control files.

The administration and configuration of the certificates including https support on the Empirum servers increases the complexity and must be weighed up. With the "Webservice Configuration" Package, Empirum offers a comfortable solution for the configuration of the Empirum servers. In addition, there is a Knowhow Center contribution to the setup of an AD certificate authority.

Further details can be found in the online help.

Agent Login with Computer Domain Account

By using the Computer Domain Account (Windows UEM Agent with SMB protocol) you can work without user accounts in the configuration files on the computers. The managed computer uses the computer account in Active Directory. This allows a dedicated revocation of permission by disabling or removing the computer account.

Note that the shares and NTFS permissions on the Empirum servers are extended accordingly.

Operating system installation (WinPE based)

The operating system is installed via WinPE and uses an agent template to configure server access. Additionally, variables are used to make some package-specific settings.

Use a dedicated user account with limited rights to access the Empirum (depot) server. This is only used during the installation phase and its information is later no longer available on the managed computer.

Matrix42 recommends to use managed local administrator passwords (LAPS) instead of providing a generally used password via the Windowsinstallation  variables "BuiltinAdministratorActive" and "BuiltinAdministratorPassword".

Domain join during or after the operating system installation

In the process of installing a Microsoft Windows operating system, the join (inclusion) of the computer into the domain is usually desired. This requires authentication with a user that has at least the authorization of an account operator. We recommend that you use a dedicated user who does not have any further rights.

Empirum Web Console (EWC)

The Empirum Web Console uses a provided Apache Tomcat version and Open JDK Java driver. These are regularly updated when the Empirum version is updated. We recommend customers who do not regularly use the latest Empirum version to update it when security critical bugs are discovered.

Matrix42 offers customers a knowledge base article on how to install a reverse proxy in IIS to enable use via https.

https://help.matrix42.com/20Unified_Endpoint_Management/20Client_Management/90Common_Issues/Empirum_Web_Console_and_the_Subdepot_Webservices_shall_communicate_via_HTTP

  • Was this article helpful?