Federating your Appliances
Overview
Starting from Nexthink V6.6, Appliances are organized around a new primary / secondary architecture called a federation. The Appliance hosting the Portal functions as primary component, while the Appliances hosting the Engines work as secondary components.
When installing a new Appliance or when updating an Appliance from V6.5 (or previous) to V6.6 (or higher), the Appliance enters what is called compatibility mode. In compatibility mode, Appliances do not profit from the benefits of federation. The main advantages of federating your Appliances include:
Centralized configuration.
Centralized and automatic updates of Appliances and Collectors.
Readiness for upcoming features.
Starting from V6.17, because of the security constraints introduced by automatic Appliance hardening, federating your Appliances is mandatory to enable the real-time communication between the Portal and the Engines.
In the case of small setups which include both the Portal and the Engine in the same Appliance, federation is automatic. In any other case, to take advantage of centralized configuration and updates and get ready for future improvements, federate your Appliances.
Federating an Appliance
Before federating a secondary with a primary Appliance, they must satisfy the following pre-requisites:
The Appliance to be federated is indeed a secondary Appliance (Engine only).
The secondary Appliance is not federated yet.
The primary and the secondary Appliances share the same version.
A bi-directional communication channel exists between the primary and the secondary Appliance.
The primary Appliance is able to reach the secondary Appliance using the internal DNS name specified for the secondary.
The secondary Appliance is able to reach the primary Appliance using the internal DNS name specified for the primary.
To federate an Appliance:
Log in to the Web Console of the primary Appliance (the Portal) as admin.
Click the Appliance tab at the top of the Web Console.
Select Federated appliances from the left-hand side menu. This option is only available if there is no Engine installed in the primary Appliance.
Click the button ADD APPLIANCE at the bottom of the page. A dialog to add the Appliance shows up.
Type in the DNS name or IP address of the secondary Appliance in Internal DNS name. This name must match the internal name that you specified for the secondary Appliance.
Type in the password of the SSH Nexthink account in the secondary Appliance as Password.
Specify the settings of the secondary that you want to control from the primary in Settings to Centralize. Tick zero or more of:
Cloud Services
Mail server
Privacy
Compliance
External backup
Click OK to federate the secondary Appliance. The Engine in the secondary Appliance is automatically restarted to apply the new configuration.
Federation process
During federation, the primary and secondary Appliances exchange their SSH public keys to enable secure bi-directional communication. In addition, the federation creates a public key infrastructure (PKI) to make the TCP connection between the Collectors and the secondary Appliances trustworthy through TLS:
The primary Appliance generates a Root Certificate, its associated private key (not shown in the figure), and a Customer Key (an ad hoc cryptographic key for the secondary Appliances to authenticate Collectors) during its installation.
When you federate a secondary Appliance, the Customer Key of the primary component is mirrored at the secondary component.
Additionally, the federation process issues a Server Certificate for the secondary Appliance based on its External DNS name and signed with the private key of the Root Certificate in the primary component.
When generating the Collector installer or the MST, download both the Root Certificate and the Customer Key from the primary Appliance and provide them as parameters to the installation, as explained in the instructions to install the Windows Collector.
After federation, the Collector authenticates a secondary Appliance by using the Root Certificate to validate the Server Certificate presented by the Appliance as part of the TLS handshake. In its turn, the secondary Appliance accepts the connection from the Collector only if the Collector has the same Customer Key as the Appliance itself. Therefore, you must always supply the correct Customer Key to the Collector during its installation:
If you replace the generated Server Certificates in the secondary Appliances by your own certificates, do not provide the generated Root Certificate when installing the Collector. By not supplying the Root Certificate, the Collector falls back to the Windows Trusted Root Certificates Store for validating your certificates instead.
Note that the communications protected by the PKI are not related to device information, but to the centralized update and other upcoming features. Collectors use a different mechanism to secure the communication of device info to the Engines via UDP.
Federating centralized settings
Centralized settings can be shared across all appliances, including the Portal and federated Engines. The corresponding configurations can be updated from the Portal appliance using specific centralized settings. This ensures that these settings are uniform and non-editable across all Engine appliances.
In the case of centralized settings, the configuration files of the primary appliance are mirrored to the secondary appliance. Therefore, you cannot change centralized settings in the secondary appliance. Centralized settings are displayed as read-only in the Web Console on the secondary appliance.
Conversely, if a user chooses not to centralize certain settings, the respective configurations cannot be copied from the Portal appliance. Instead, it remains editable and can be configured differently for each engine appliance.
Select the following checkboxes on all federated engines:
Cloud Services
Mail Server
Privacy
Compliance
External Backup
This forces all Engine appliances to share the same compliance configurations for these categories as updated from the Portal, ensuring consistency in compliance settings across the entire system.
Appliance management and connection to Engines from the Portal
Two management tasks in the Portal overlap to some extent with the features of federating your Appliances:
Connection to the Engines
Appliance management
Regarding the connection to the Engines, you still need to connect your Portal to the Engines, even after federation, for the Portal to be able to collect data.
As for Appliance management, it is still available in the Portal, but two of its features have been disabled because they are overridden by federation:
SMTP configuration (overridden by the Mail server centralized settings).
Central update (overridden by the centralized update of federated Appliances).
RELATED TASKS
RELATED REFERENCES
Last updated
