Federating your Appliances
Federating your Appliances
Starting from Nexthink V6.6, Appliances are organized around a new master / slave architecture called a federation. The Appliance hosting the Portal functions as master, while the Appliances hosting the Engines work as slaves.
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 slave with a master Appliance, they must satisfy the following pre-requisites:
- The Appliance to be federated is indeed a slave Appliance (Engine only).
- The slave Appliance is not federated yet.
- The master and the slave Appliances share the same version.
- A bi-directional communication channel exists between the master and the slave Appliance.
- The master Appliance is able to reach the slave Appliance using the internal DNS name specified for the slave.
- The slave Appliance is able to reach the master Appliance using the internal DNS name specified for the master.
To federate an Appliance:
- Log in to the Web Console of the master 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 master 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 slave Appliance in Internal DNS name. This name must match the internal name that you specified for the slave Appliance.
- Type in the password of the SSH Nexthink account in the slave Appliance as Password.
- Specify the settings of the slave that you want to control from the master in Settings to Centralize. Tick zero or more of:
- Cloud Services
- Mail server
- External backup
- Click OK to federate the slave Appliance. The Engine in the slave Appliance is automatically restarted to apply the new configuration.
During federation, the master and slave 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 slave Appliances trustworthy through TLS:
- The master 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 slave Appliances to authenticate Collectors) during its installation.
- When you federate a slave Appliance, the Customer Key of the master is mirrored at the slave.
- Additionally, the federation process issues a Server Certificate for the slave Appliance based on its External DNS name and signed with the private key of the Root Certificate in the master.
- When generating the Collector installer or the MST, download both the Root Certificate and the Customer Key from the master 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 slave 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 slave 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 slave 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.
As for the centralized settings, the configuration files of the master Appliance are mirrored at the slave. Thus, in the slave Appliance, it is no longer possible to change the centralized settings, which are displayed as read-only in the Web Console.
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).