The Concept and Architecture of Isolated XTAM Nodes
You install an XTAM node in an isolated network to provide access to assets in this network and to execute jobs such as password resets on the assets in the isolated network. One node in the isolated network will serve all assets it can access within this network. In this scenario, users gain access to all assets from this isolated network through the main XTAM node, while the isolated node works transparently behind the scenes to serve these assets. This is not a high availability setup because both nodes have access to different assets (one in the main network and the other one in the isolated network) so you need both of them to operate. When the main node is down, no access is possible to anything.
The following is a description of the architecture to design an isolated Session Manager (for sessions) and isolated Job Engine (for task execution like password resets) deployment. This is a conceptual description to illustrate the architecture to help with design decisions. For details and configuration options, please read the appropriate guide linked below.
The isolated node should be installed using its internal database and then configured to serve as an isolated node. It does not need to connect to the same database the main XTAM node is connected as this deployment scenario assumes that the back end database of the main XTAM node is not accessible by the isolated node from inside of its network.
To provide remote access to assets in the isolated network, the main node needs to connect to the Session Manager in the isolated network using the proprietary XTAM protocol, which it does using port 4822. This port should be opened in the isolated network firewall to the XTAM isolated node for the main node to connect. The Session Manager traffic between the main node and the isolated node is secured by the certificates exchanged between the nodes. To configure this you will need to bring this certificate from the main XTAM node to this isolated node during configuration.
Lastly, the main node should have a configuration in the Administration > Settings > Proximity Groups screen instructing the main node to route traffic for certain assets to the isolated node. There are several criteria you can choose from:
- route all traffic to certain IP addresses to the isolated node and all other assets will be served by the main node
- route all traffic to certain computer names (by DNS name masks) to the isolated node and all other assets will be served by the main node
- route all traffic for all assets locates in certain XTAM Vault (folder) to the isolated node and all other assets will be served by the main node
Use Case #2, Network Isolation, in the below article provides additional details:
To make the isolated node for task executions like password reset jobs on the assets inside the isolated network, you need to create a Service user in the main node using the Administration > Local Users screen. After that, you need to designate this user account as a Service using Administration > Global Roles screen. Lastly, you need to grant this user permissions (Owner with Execute rights) for the assets the isolated node should serve. This permission could be granted for the Vault, Folder or for individual Records. The isolated node, when configured, will execute jobs only for the assets with this user in permission sets. The main XTAM node will not execute jobs for the assets designated for the isolated node.
After the service user is created, connect the isolated node to the main node by using the XTConnect command, providing the https URL of the main node and credentials of the service user created earlier. After this command, the isolated node will communicate with the main node using HTTPS traffic from inside of the isolated network. The main node should be available for the isolated node to connect using the regular URL (port 443 should be opened in the main node firewall, you can check this by browsing main node from the isolated node). When properly configured, the isolated node will poll the main node for the jobs to execute for the assets designated for the isolated node by means of the permissions granted for the service account, execute those jobs for the local assets and send results back to the main XTAM node.
Use Case #2, Remote Job Engines operating in isolated networks, in the below article provides additional details:
More isolated network nodes could be added in a similar fashion by using additional proximity groups for session managers and additional service accounts to designate assets for task execution by these remote nodes. One of the design decisions in content organization is how to group assets for the isolated nodes to simplify management. The simplest solution is to put all assets related to the isolated network into a corresponding XTAM Vault to set up Session Manager proximity group to this vault and to grant permissions to the service account on the vault level. There are other solutions for this designation too.