Secure Hub and Robot

uim902
secure_hub_robot
With newer security issues coming up every single day, organizations cannot ignore the focus on the continuous enhancement of their product's security. Understanding the importance of heightened security, UIM further enhances its security by allowing its customers to seamlessly move to secure hub and robot. Now, two types of hubs and robots are available—
secure
and
non-secure
. In this UIM version, secure hub (hub_secure) and secure robot (robot_update_secure) are available, which further improve the security in UIM. Secure hub and robot provide robust hub-to-hub and robot-to-hub communication. UIM 9.0.2 and prior releases ship with the
non-secure
hub and robot, which use the legacy security model.
A UIM hub serves as the communication center for a group of robots. A hub binds robots into a logical group with the hub as the central connection point. Hubs are typically set up based on a location (such as a lab or a building) or by service (such as development). A hub can connect other hubs into a hierarchy of hubs. UIM lets you decide whether you want to use the secure hub and robot setup. You can use the UIM upgrade installer to upgrade your existing UIM setup to a secure setup. You can do this by selecting the secure option while installing UIM Server. Based on your selection, appropriate configurations are performed in your UIM environment.
The following topics cover the required information:
Introduction
General Architecture
The general architecture applies to both non-secure and secure hubs and robots. Architecturally, a hub is a robot that gains management capabilities through the presence of the
hub probe
. Configure the probe to modify how the hub handles the following UIM services:
  • Message distribution
    Messages from robots are routed through the hub. Messages are routed to other hubs, or dispatched to local subscribers (users and probes).
  • Name service
    The hub translates a
    /domain/hub/robot/probe
    address into an IP address and port. The service registers TCP/IP addresses at startup. Registration allows applications to connect to the service using TCP/IP.
    This is not applicable for secure hub and robot. In a secure setup, this functionality is achieved by using tunnels.
  • Authentication
    The hub handles logins to the domain.
  • Authorization
    The hub verifies user access rights to probes and the infrastructure (hub, robot, and spooler).
  • Tunneling
    Hub-to-hub tunnels enable secure communication from one site to another site, much like a VPN.
Secure Hub and Robot Architecture
In addition to the general architectural components above, the secure hub and robot:
  • Establish a strong trust relationship between hubs, and between hubs and robots.
  • Proxy the communications to and from all probes, including the hub and controller.
  • Use encrypted, trusted transport.
  • Ensure that probes listen only on the loopback address. Non-encrypted and non-trusted inter-server probe-to-probe communication is prevented.
  • Support third-party certificate authorities and PKI. Self-signed certificates are supported, but are not recommended.
  • Replace the legacy Secure Sockets Layer (SSL) mode, proxy mode, and passive mode.
  • Support mixed-mode implementations. Mixed mode allows non-secure and secure hubs and robots to coexist.
  • Provide secure access to the UIM message bus. For example, callbacks above READ level from remote robots are not allowed.
  • Implement enhanced password hashing with the (PBKDF2) hashing algorithm.
  • Do not support any communication between hub-to-hub without tunnels.
Secure Hub and Robot Version Format
The secure hub and robot package names follow a format that is different from the non-secure ones. Review that the package names have been suffixed with
_secure
to distinguish them from the non-secure ones:
  • hub_secure 9.31S
  • robot_update_secure 9.31S
The non-secure hub and robot packages follow the same format that is applicable for the previous releases:
  • hub 9.31
  • robot_update 9.31
Mixed Mode
In large installations, where many hubs connect to many robots, upgrading all the hubs and robots at once is impractical. To avoid a loss of communication during the upgrade, incremental upgrades are supported. Secure hubs can communicate with non-secure robots when the hub_adapter probe is installed on the secure hubs. A mixed-mode environment consists of both secure and non-secure hubs and robots in a UIM domain.
The following diagram illustrates an example of mixed-mode implementation.
  • A
      Secure hubs communicate only through tunnels.
  • B
    The controller handles communication between secure hubs and robots. The communication is encrypted.
  • C
    Non-secure hubs and robots continue to use non-encrypted transport.
  • D
    All internal communication between components that are installed on a secure server occur over the loopback.
Mixed_Mode_Secure_NonSecure
Mixed_Mode_Secure_NonSecure
Considerations
Review the following considerations:
Existing UIM Environment
  • Before you upgrade to secure hub and robot, review the Supported Upgrade Path article to know the correct upgrade path.
  • In an existing UIM setup, if your primary hub is not a tunnel server or tunnel client, the upgrade installer converts the primary hub into a tunnel server (if the secure option is used). Additionally, all other hubs that point to the primary hub are made tunnel clients to that primary hub. It is not ideal to have a primary hub as a tunnel server, but it might be useful in very small environments or for demonstrating proof of concepts (PoCs). However, in production environments, it is recommended that you always make your primary hub as a tunnel client.
Hubs and Robots
  • In a secure environment, it is recommended that the latest distsrv probe is installed on all the hubs that you want to change to secure hubs. This helps in recovering from any failure. Once moved to a secure setup, there is a possibility of losing connection with the primary hub. When you have distsrv, you can directly connect to the IM of the failing hub and restore to the older version.
  • To avoid losing connectivity, the tunnel server hub is upgraded first, followed by tunnel client hubs. All hubs require hub-to-hub tunnel connections. Use tunnels for communication between secure hubs, and for communication between non-secure and secure hubs. Static routes between hubs are not supported.
  • The hub_adapter probe is added to a hub before upgrading the hub robot.
  • After making your environment secure, if you want to add more robots or hubs to your secure environment, you can do so. For more information about how you can add a new robot or hub, see the Add a New Robot or Hub to a Secure Environment sections.
  • Tunnel security is enhanced with the secure hub. It is possible to maintain a mixed-mode environment, where some hubs are secure and some are non-secure.
  • A secure hub can communicate with a non-secure hub provided both the hubs share the same certificates (for example, signed by the same certificate authority (CA)).
  • Do not install any hub on a Dynamic Host Configuration Protocol (DHCP) client.
  • We recommend that all hubs and robots (pointing to those hubs) use the same certificate authority (CA).
  • The cipher security setting on the tunnel server must be set to High. Otherwise, no communication happens if any hub in the domain is made secure.
  • In a
    non-secure to secure
    upgrade scenario, when you deploy the hub_secure or robot_update_secure packages, an error message is shown that states that the deployment has been aborted. However, the deployment completes without any issue. If you receive this error, you can ignore it.
ssl_mode Support (Deprecated)
  • The parameter ssl_mode is deprecated. With 9.2.0, by default, SSL communication is enabled between robot and hub through secure bus, if the secure option is selected during the 9.2.0 upgrade. Therefore, secure bus can be considered as an alternative to ssl_mode. If the non-secure option is selected during the upgrade, ssl_mode will not have any impact.
Fully Qualified Domain Names (FQDNs)
  • Fully Qualified Domain Names (FQDNs) are required for validation. If short hostnames are used, the validation fails. If Domain Name System (DNS) is not properly configured, you need to explicitly provide FQDNs and create hosts file entries. Ensure that you add FQDNs of OC, CABI, and other independent robots to the etc/hosts file on the hub from which you are performing the deployment. Similarly, you also need to add FQDNs of the respective hubs to the OC, CABI, and other independent robots. FQDN name resolutions need to be set in the hosts file on the first line.
Package Renaming
  • We recommend that you do not rename the package name in the archive. If you rename the package name in the archive and try to deploy the package to the hub after logging into the same hub, an unexpected error can appear. However, deployment is completed correctly. For example, if you rename the robot_update package in the archive and try to deploy it to the hub after logging into that hub, you get the following error:
    Aborted, retry limit exceeded, unknown status
    , but the deployment completes successfully.
Backup
  • Back up security.cfg and security.dta before the upgrade.
Certificate Package
  • (For 20.3.3 and later) Follow the instructions in the Secure Transmission of Certificates article to securely transfer the certificates from the hub to the required robots (hub robots, UMP/OC robot, CABI robot, and other independent robots) pointing to that hub.
  • (Prior to 20.3.3) The create_robot_cert_package callback has a dependency on the latest version of the distsrv probe or automated_deployment_engine (ade) probe released with 20.3.0. This callback is used to generate the UIMRobotCert package. Ensure that the latest version of distsrv or ade is already deployed to the secure tunnel server hub where you run the callback to create the package. If the latest version of both the probes is available, the callback uses distsrv by default. If distsrv is not available, it uses the ade probe.
Infrastructure Manager
The following considerations are related to Infrastructure Manager (IM). Infrastructure Manager is a configuration interface for UIM. IM is supported only on Windows platforms. Typically, you log in to the primary hub on IM.
  • In a secure UIM environment, you can use IM only on a Windows system that is converted to a secure hub. IM can connect to the loopback address (127.0.0.1) of the local system and can navigate to other hubs. This implies that remote IM connections are no longer available.
  • To use IM in a mixed-mode UIM domain:
    • If the primary hub is secured, and is
      non-Windows
      , log in to any non-secure hub in the domain.
    • If the primary hub is secured, and is
      Windows
      , install IM on the Windows primary hub. Connect to the domain using the Windows loopback IP address of 127.0.0.1.
    • If a secondary Windows hub is secured, install IM on the Windows secondary hub. Connect to the domain using the Windows loopback IP address of 127.0.0.1.
  • To use IM in a secured UIM domain:
    • If the primary hub is on a Windows platform, install IM on the Windows primary hub. Connect to the domain using the Windows loopback IP address of 127.0.0.1.
    • If the primary hub is non-Windows, install IM on a Windows secondary hub. Connect to the domain using the Windows loopback IP address of 127.0.0.1.
  • In a secure environment, the
    Alarm Window
    section (
    View, Alarm Window
    ) does not open in IM. Furthermore, after clicking
    View, Alarm Window
    , if you refresh your IM (
    View, Refresh
    ), you will lose the connectivity to all the hubs. You must log in again to view all the hubs in IM.
    If you want to view the
    Alarm Window
    section in a secure environment, you can install IM on a secure (or non-secure) secondary hub and point the alarm window to the primary hub nas. To do so, select
    Tools, Options
    from the menu bar and then select the primary hub nas option (for example, /<domain_name>/<primary_hub_name>/<primary_hub_robot_name>/nas) from the
    Alarm Server
    drop-down list.
UMP/OC
and CABI
  • For upgrading your UMP/OC and CABI in a secure setup, ensure that you bring your UMP/OC and CABI robots to the secure state by deploying the appropriate certificates and then updating the version to the secure versions. After that, you upgrade UMP/OC and CABI.
Upgrade Existing UIM Setup to Secure Hub and Robot
If your primary hub is not a tunnel server or tunnel client, the upgrade installer converts your primary hub into a tunnel server (when the secure option is used). It also converts other hubs that are pointing to that primary hub into tunnel clients. It is not ideal to have a primary hub as a tunnel server, but it might be useful in very small environments or for demonstrating proof of concepts (PoCs). However, in production environments, it is recommended that you always make your primary hub as a tunnel client.
UIM supports the following upgrade scenarios for the secure bus:
  • Existing Environment Configured without Tunnels
  • Existing Environment Configured with Tunnels (Primary Hub as Tunnel Server)
  • Existing Environment Configured with Tunnels (Primary Hub as Tunnel Client) 
The process to upgrade your existing UIM environment to a secure setup involves the following tasks:
Secure_Upgrade_Process.jpg
After securing your setup, if you want to add more robots or hubs to the secure environment at a later stage, you can do so. For more information about how you can add a new robot or hub, see the Add a New Robot or Hub to a Secure Environment sections.
Upgrade Existing Environment Configured without Tunnels
In this scenario, your existing environment is not configured with tunnels. The steps are as follows:
  1. Upgrade UIM Server (Primary Hub)
  2. Upgrade Secondary Hubs
  3. Upgrade UMP/OC
  4. Upgrade CABI
  5. Upgrade Other Robots
Upgrade UIM Server (Primary Hub)
The upgrade installer (UIM Server) provides an option that lets you automatically deploy secure hub and robot binaries to the primary hub in your existing setup. When you run the upgrade installer, you get a secure option to upgrade your existing hub and robot to secure hub and robot. When the upgrade completes, depending on your existing setup, the upgrade performs the appropriate tasks as outlined in this section.
Follow these steps:
  1. Run the setupCAUIMServer.exe file on the computer where your existing UIM Server is installed.
    The
    Upgrade Detected
    screen appears.
  2. Review the installed version and upgrade version information, and click
    Next
    .
    The
    License Agreement
    screen appears.
  3. Review the license information, accept the agreement, and click
    Next
    .
    The
    Secure Bus Configuration
    screen appears. You use this screen to provide information that performs secure hub- and robot-related configurations in your environment.
    Secure_Hub_Robot_Options.PNG
  4. Perform the following actions on this screen to upgrade to secure hub and robot:
    • Enable
      Specifies whether you want to upgrade to secure hub and robot.
    • Tunnel Server Configuration
      Lets you specify configuration settings for the tunnel server. This information configures the primary hub as a tunnel server, makes tunnel server as a certificate authority (CA), creates * tunnel certificates.
      • Tunnel Server Port
        Enter the tunnel server port number, and click
        Test
        to verify the port availability. The default port is 48003.
      • CA/Server Password
        Enter the password that you want to use for generating the certificate authority (CA) and tunnel server certificate (CN: IP address).
      • Confirm CA/Server Password
        Confirm the password that you entered in the
        CA/Server Password
        field.
      • Client Password
        Enter the password that you want to use for the tunnel client certificate. This password is used to generate the * (wildcard) tunnel client certificates.
      • Confirm Client Password
        Confirm the password that you entered in the
        Client Password
        field.
  5. Click
    Next
    .
    The
    Upgrade Preparation
    screen appears.
  6. Enter the password associated with the UIM administrator, and click
    Run Upgrade Preparation
    . During this phase, the following tasks are performed based on the existing setup. More information about these scenarios is explained after the procedure steps:
    1. If the primary hub is configured as a tunnel server in the existing setup, a duplicate of the certificate is copied to the
      <Nimsoft>\robot\certs
      folder and robot.cfg is appropriately configured with the certificate location.
    2. If the primary hub is configured as a tunnel client in the existing setup, a duplicate of the certificate is copied to the
      <Nimsoft>\robot\certs
      folder and robot.cfg is appropriately configured with the certificate location.
    3. If no tunnels exist in the existing setup, the primary hub is configured as a tunnel server and all secondary hubs pointing to that primary hub are configured as tunnel clients.
    When the upgrade preparation is done, the
    Pre-Install Summary
    screen appears.
  7. Review the information; for example, verify
    Secure Bus Configuration
    section.
  8. Click
    Install
    to start the upgrade process.
    When the upgrade process is completed, the
    Install Complete
    screen appears.
  9. Click
    Done
    .
In this scenario, when you enable the secure option, the behavior is as follows:
  • The upgrade installer configures the primary hub as a tunnel server.
  • The upgrade installer configures all secondary hubs that are pointing to the primary hub as tunnel clients.
  • The upgrade installer makes tunnel server (primary hub) as the certificate authority (CA), creates a tunnel server certificate, and * tunnel client certificate (signed by the created CA) in the
    <Nimsoft>\hub\certs
    folder. An example snippet is as follows:
    ca.pem cert01.pem server.ca.ec.cert.pem server.ec.cert.pem server.ec.key.pem ....
  • The upgrade installer updates the tunnel server (primary hub) hub.cfg with the created tunnel server certificates location. An example snippet is as follows:
    <server> ... ca_location = certs/server.ca.ec.cert.pem public_cert = certs/server.ec.cert.pem private_key = certs/server.ec.key.pem password = +2U4jzflzhj01loXVWQ== </server>
  • The upgrade installer updates the tunnel server (primary hub) robot.cfg with the created tunnel certificates location. An example snippet is as follows:
    <controller> ... proxy_ca_location = C:\Program Files (x86)\Nimsoft\.\hub\certs\server.ca.ec.cert.pem proxy_cert = C:\Program Files (x86)\Nimsoft\.\hub\certs\server.ec.cert.pem proxy_private_key = C:\Program Files (x86)\Nimsoft\.\hub\certs\server.ec.key.pem proxy_private_key_password = +2U4jzflzhj01loXVWQ== proxy_check_ip_first = 1 </controller>
  • The upgrade installer creates a * tunnel client certificate in the tunnel clients (secondary hubs)
    <Nimsoft>\hub\certs
    folder. An example is as follows:
    client1.pem ...
  • The upgrade installer updates the tunnel clients (secondary hubs) hub.cfg with the created certificate location. An example is as follows:
    ... cert = certs/client1.pem password = +2U4jzflzhj01loXVWQ==
  • The upgrade installer creates the
    <Nimsoft>\robot\certs
    folder on the tunnel clients (secondary hubs) and creates the * tunnel client certificate in this location. An example snippet is as follows:
    robotclient1.pem ...
  • The upgrade installer updates the tunnel clients (secondary hubs) robot.cfg with the created certificate location. An example snippet is as follows:
    <controller> ... proxy_ca_location = robot/certs/robotclient1.pem proxy_cert = robot/certs/robotclient1.pem proxy_private_key = robot/certs/robotclient1.pem proxy_private_key_password = +2U4jzflzhj01loXVWQ== proxy_check_ip_first = 1 </controller>
  • The upgrade installer deploys the hub_adapter, secure hub, and secure robot to the tunnel server (primary hub).
    The following example screenshot shows that the required secure packages are successfully deployed to the primary hub (which is a tunnel server in this example):
    Secure_primary_hub_tunnel_server
Your primary hub is now secure.
Upgrade Secondary Hubs
After the upgrade installer performs required tasks, you can now configure secondary hubs and make them secure.
Follow these steps:
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  2. From the primary hub archive, deploy the hub_adapter probe to the secondary hubs (tunnel clients).
    The following example screenshot shows that the hub_adapter probe is successfully deployed to the secondary hub:
    Hub_adapter_deployed_on_secondary_hub.PNG
  3. From the primary hub archive, deploy the latest non-secure robot (7.97 or later) to the secondary hubs (tunnel clients).
    The following example screenshot shows that the non-secure robot is successfully deployed to the secondary hub:
    Robot_non_secure_on_secondary_hub.PNG
  4. From the primary hub archive, deploy the latest secure hub to the secondary hubs (tunnel clients).
    The following example screenshot shows the secure hub is successfully deployed to the secondary hub:
    Secure_hub_on_secondary_hub.PNG
  5. From the primary hub archive, deploy the latest secure robot to the secondary hubs (tunnel clients).
    The following example screenshot shows the secure robot is successfully deployed to the secondary hub:
    Secure_Robot_on_Secondary_hub.PNG
  6. From the primary hub archive, deploy the latest distsrv (9.20 or later) probe to the secondary hubs.
    The following example screenshot shows that the distsrv 9.20 is successfully deployed to the secondary hub:
    Distsrv_on_secondary_hub.PNG
Your secondary hubs are now secure.
Upgrade UMP/OC
After upgrading your secondary hubs, you can convert your UMP/OC to a secure state.
Follow these steps:
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  2. (For 20.3.3 and later) Follow the instructions in theSecure Transmission of Certificates article to securely transfer the certificates from the hub to the robots pointing to the hub.
  3. (Prior to 20.3.3) Use the certificate generation callback on the secure tunnel server hub to create a certificate package (UIMRobotCert) in the local archive of the secure tunnel server. This certificate package contains the * tunnel certificate .pem file and robot.cfx. When you deploy this package, it deploys the certificate .pem file and updates the robot.cfg file with the .pem file location. For more information about how to generate the certificate, see the certificate generation section in this article. From the primary hub archive, deploy the certificate package (UIMRobotCert) to the UMP/OC robot.
  4. From the primary hub archive, upgrade the UMP/OC robot version to the secure version.
  5. Run the OC installer to upgrade UMP to OC.
Your OC deployment is now secure and is upgraded.
Upgrade CABI
You can now upgrade your CABI to the secure state.
Follow these steps:
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  2. (For 20.3.3 and later) Follow the instructions in the Secure Transmission of Certificates article to securely transfer the certificates from the hub to the robots pointing to the hub.
  3. (Prior to 20.3.3) In the primary hub archive, locate the UIMRobotCert package that you have already created and deploy it to the CABI robot.
  4. Upgrade the CABI robot version to the secure version.
  5. Deploy the latest CABI package to the CABI robot.
Your CABI deployment is now upgraded and is secure.
Upgrade Other Robots
If there are other independent robots in your domain that you want to make secure, you can do so.
Follow these steps:
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  2. (For 20.3.3 and later) Follow the instructions in the Secure Transmission of Certificates article to securely transfer the certificates from the hub to the robots pointing to the hub.
  3. (Prior to 20.3.3) In the primary hub archive, locate the UIMRobotCert package that you have already created and deploy it to the independent robots.
  4. From the primary hub archive, upgrade the independent robot version to the secure version.
Your independent robots are now secure.
Upgrade Existing Environment Configured with Primary Hub as Tunnel Server
Your existing environment is configured with tunnels. In this setup, your primary hub is configured as a tunnel server and all other secondary hubs are configured as tunnel clients. The steps are as follows:
  1. Upgrade UIM Server (Primary Hub)
  2. Upgrade Secondary Hubs
  3. Upgrade UMP/OC
  4. Upgrade CABI
  5. Upgrade Other Robots
Verify that the cipher security setting on the tunnel server is set to High. Otherwise, no communication happens if any hub in the domain is made secure.
Upgrade UIM Server (Primary Hub)
To run the UIM Server upgrade installer, follow the steps as explained in the previous section. As tunnels are already configured in the existing setup, the
Tunnel Server Configuration
section is not displayed.
In this scenario, when you enable the secure option, the behavior is as follows:
  1. The upgrade installer does not change the existing tunnel setup.
  2. The upgrade installer deploys the hub_adapter, secure hub, and secure robot to the primary hub (tunnel server).
    The following example screenshot shows that the required secure packages are deployed to the primary hub (which is a tunnel server in this screenshot and scenario):
    Primary_Hub_Tunnel_Server_Secure.PNG
Your primary hub is now secure.
Upgrade Secondary Hubs
After the upgrade installer performs required tasks, you can now configure secondary hubs and make them secure.
Follow these steps:
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
    The following example screenshot shows the login to the IM on the secure primary hub using the loopback IP address:
    Secure_Primary_Hub_Login.PNG
    You can see all your secondary hubs listed because tunnels are already configured.
    The following example screenshot shows that a secure primary hub (tunnel server) and non-secure secondary hub (tunnel client) are listed in the IM after the login on the secure primary hub:
    Primary_Hub_Second_Hub_Listed.PNG
  2. From the primary hub archive, deploy the latest hub_adapter probe to the secondary hubs (tunnel clients).
    The following example screenshot shows that the hub_adapter probe is successfully deployed to the secondary hub:
    Hub_Adapter_on_Secondary_Hub.PNG
  3. From the primary hub archive, deploy the latest non-secure robot to the secondary hubs (tunnel clients).
    The following example screenshot shows that the non-secure robot is successfully deployed to the secondary hub:
    NS_Robot_on_Secon_Hub.PNG
  4. From the primary hub archive, deploy the latest secure hub package to the secondary hubs (tunnel clients).
    The following example screenshot shows that the secure hub is successfully deployed to the secondary hub:
    Secure_Hub_on_Second_Hub.PNG
  5. From the primary hub archive, deploy the latest distsrv (9.20 or later) to the secondary hubs.
    The following example screenshot shows that distsrv 9.20 or later is successfully deployed to the secondary hub:
    Distsrv_on_Second_Hub.PNG
  6. (For 20.3.3 and later) Follow the instructions in the Secure Transmission of Certificates article to securely transfer the certificates from the hub to the robots pointing to the hub.
  7. (Prior to 20.3.3) Use the robot certificate callback on the secure tunnel server hub to create a certificate package (UIMRobotCert). This certificate package contains the * tunnel certificate .pem file and robot.cfx. When you deploy this package, it deploys the certificate .pem file and updates the robot.cfg file with the same .pem file location. From the primary hub archive, deploy the certificate package (UIMRobotCert) to the secondary hub robots, UMP/OC robot, CABI robot, and other independent robots
  8. From the primary hub archive, deploy the latest secure robot package to secondary hub robots.
    The following example screenshot shows that the secure robot package is successfully deployed to the secondary hub:
    Secure_Robot_on_Secondary_hub.PNG
Your secondary hubs are now secure.
Upgrade UMP/OC
After upgrading your secondary hubs, you can secure your UMP/OC deployment.
Follow these steps:
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  2. From the primary hub archive, upgrade the UMP/OC robot version to the secure version.
  3. Run the OC installer to upgrade UMP to OC.
Your OC deployment is now secure and is upgraded.
Upgrade CABI
You can now upgrade your CABI to the secure state.
Follow these steps:
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  2. From the primary hub archive, upgrade the CABI robot version to the secure version.
  3. Deploy the CABI 4.30 package to the CABI robot.
Your CABI deployment is now upgraded and is secure.
Upgrade Other Robots
If there are other independent robots in your domain that you want to make secure, you can do so.
Follow these steps:
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  2. From the primary hub archive, upgrade the robot version to the secure version.
Your independent robots are now secure.
Upgrade Existing Environment Configured with Primary Hub as Tunnel Client
Your existing environment is configured with tunnels. In this setup, your primary hub is configured as a tunnel client, one of the secondary hubs is configured as a tunnel server, and remaining secondary hubs are configured as other tunnel clients. The steps are as follows:
  1. Upgrade UIM Server (Primary Hub)
  2. Upgrade Secondary Hubs
  3. Upgrade UMP/OC
  4. Upgrade CABI
  5. Upgrade Other Robots
Verify that the cipher security setting on the tunnel server is set to High. Otherwise, no communication happens if any hub in the domain is made secure.
Upgrade UIM Server (Primary Hub)
To run the UIM Server upgrade installer, follow the steps as explained in the previous section. As tunnels are already configured in the existing setup, the
Tunnel Server Configuration
section is not displayed.
In this scenario, when you enable the secure option, the behavior is as follows:
  1. The upgrade installer does not change the existing tunnel setup. It duplicates the certificate used in the tunnel client configuration in the primary hub and places it in the ..\
    Nimsoft\robot\certs
    folder. The robot is configured to use that certificate.
  2. The upgrade installer deploys the hub_adapter, secure hub, and secure robot to the primary hub (tunnel client).
Your primary hub is now secure. The following example screenshot shows that the secure packages are deployed to the primary hub (which is a tunnel client in this screenshot):
Primary_Hub_Secure.PNG
Upgrade Secondary Hubs
After the upgrade installer performs required tasks, you can now configure secondary hubs and make them secure. One of the secondary hubs is a tunnel server in this scenario.
Follow these steps:
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP). The following example screenshot shows the primary hub IM login using the loopback IP:
    Primary_Hub_Loopback_Login.PNG
    You should be able to see all your secondary hubs listed because tunnels are already configured. The following example screenshot shows the non-secure secondary hub (which is a tunnel server in this screenshot) and the secure primary hub after the IM login:
    Phub_Shub_Listing.PNG
  2. From the primary hub archive, deploy the latest hub_adapter probe to the secondary hubs.
    The following example screenshot shows that the hub_adapter probe is successfully deployed to the secondary hub:
    Hub_Adapter_on_Sec_hub.PNG
  3. From the primary hub archive, deploy the latest non-secure robot to the secondary hubs.
    The following example screenshot shows that the non-secure robot is successfully deployed to the secondary hub:
    NS_Robot_on_Sec_Hub.PNG
  4. Deploy the secure hub to the secondary hubs.
    The following example screenshot shows that the secure hub is successfully deployed to the secondary hub:
    Secure_hub_on_SecHub.PNG
  5. Deploy the latest distsrv to the secondary hubs.
    The following example screenshot shows that distsrv 9.20 or later is successfully deployed to the secondary hub:
    Distsrv_on_Sec_hub.PNG
  6. (For 20.3.3 and later) Follow the instructions in the Secure Transmission of Certificates article to securely transfer the certificates from the hub to the robots pointing to the hub.
  7. (Prior to 20.3.3) Connect to IM from any Windows computer by using the normal IP of the tunnel server. Use the robot certificate callback on the secure tunnel server hub to create a certificate package (UIMRobotCert). This certificate package contains the * tunnel certificate .pem file and robot.cfx. When you deploy this package, it deploys the certificate .pem file and updates the robot.cfg file with the same .pem file location. From the tunnel server archive, deploy this certificate package to the secondary hub robots, UMP/OC robot, CABI robot, and independent robots.
  8. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  9. From the primary hub archive, deploy the latest secure robot package to secondary hubs.
    The following example screenshot shows that the secure robot is successfully deployed to the secondary hub:
    Secure_Robot_on_SecHub.PNG
Your secondary hubs are now secure.
Upgrade UMP/OC
After upgrading your secondary hubs, you can convert your UMP/OC to a secure state.
Follow these steps:
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  2. From the primary hub archive, upgrade the UMP/OC robot version to the secure robot version.
  3. Run the OC installer to upgrade UMP to OC.
Your UMP/OC is now upgraded and is secure.
Upgrade CABI
You can now upgrade your CABI to the secure state.
Follow these steps:
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  2. From the primary hub archive, upgrade the CABI robot version to the secure version.
  3. Deploy the CABI 4.30 package to the CABI robot.
Your CABI is now upgraded and is secure.
Upgrade Other Robots
You can now upgrade other independent robots to the secure state.
Follow these steps:
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  2. From the primary hub archive, upgrade the independent robot version to the secure version.
Your independent robots are now secure.
Existing Environment Configured with Partial Tunnel Setup
It is not ideal to have a primary hub as a tunnel server, but it might be useful in very small environments or for demonstrating proof of concepts (PoCs). However, in production environments, it is recommended that you always make your primary hub as a tunnel client.
A partial tunnel setup implies all the hubs in your existing setup are not communicating through tunnels. Consider a scenario where tunnels are configured only on the secondary hubs and not on a primary hub. In this case, when you run the upgrade installer by using the secure option, your primary hub will be made a tunnel server and all other secondary hubs that point to the primary hub will become tunnel clients to the tunnel server (primary hub).
Therefore, to work in this type of scenario, you must manually configure tunnels in your environment so that one of the secondary hubs in the domain is configured as a tunnel server and all other hubs as tunnel clients to that hub (tunnel server). After that, you use the upgrade installer as you do in the case where tunnels are already configured in the setup and primary hub is a tunnel client.
(Applicable for Prior to 20.3.3) Generate Certificate Package
Use the
create_robot_cert_package
hub callback on the
secure tunnel server
to generate a * (wildcard) certificate package. The callback creates the certificate package (UIMRobotCert) and places it in the secure tunnel server archive. This package includes a * certificate .pem file (client#.pem) and robot.cfx file.
Deploy this package to the required non-secure robot (for example, tunnel client robot, independent robot, UMP/OC robot, CABI robot) that you want to secure. When you deploy this certificate package to a robot that you want to secure, the package deploys the * certificate .pem file in the
<Nimsoft>\robot\certs
folder and updates the robot.cfg file with the .pem file location.
Ensure that the latest version of the distsrv probe or ade probe (released with 20.3.0) is already deployed to the secure tunnel server for this callback to work properly. If the latest version of both the probes is available, the callback uses distsrv by default. If distsrv is not available, it uses the ade probe.
Follow these steps:
  1. Open the probe utility (pu) for the secure tunnel server hub.
  2. Select the
    create_robot_cert_package
    callback from the drop-down list as shown in the following screenshot:
    Certification_Package_Creation.png
  3. Provide appropriate information for the following parameters:
    1. countryName
      (Optional)
    2. stateOrProvince
      (Optional)
    3. localityName
      (Optional)
    4. organizationName
      (Optional)
    5. emailAddress
      (Optional)
    6. commonName
      (Mandatory)
      Specify the common name as * (wildcard) to generate a * tunnel certificate.
    7. days
      (Mandatory)
      Specify the validity of the certificate.
    8. password
      (Mandatory)
      Specify the password for the certificate.
    If you try to run this callback without providing values for the mandatory parameters (
    commonName
    ,
    days
    , and
    password
    ), the callback displays the invalid argument error.
  4. Run the command request.
    When the command is successfully completed, the robot client certificate package (UIMRobotCert) is created and is added to the secure tunnel server archive.
  5. Deploy this certificate package to the robots that you want to secure.
Add a New Robot to a Secure Environment
If you want to add a new robot to a secure environment, you can use the appropriate method depending on your requirements:
  • Add a Robot Without Using a Non-Secure Secondary Hub
  • Add a Robot Using a Non-Secure Secondary Hub
  • Add a Robot Using UMP/OC
  • Add a Robot Using an XML File
Add a Robot Without Using a Non-Secure Secondary Hub
You can directly add a robot to the secure setup.
This procedure is not applicable for Linux. For Linux, you must have a non-secure secondary hub in your secure setup. Therefore, for Linux, see the Add a Robot Using a Non-Secure Secondary Hub section.
Follow these steps:
  1. Ensure that the secure hub to which you want to add a new robot already has hub_adapter enabled on it.
  2. Download the robot installer (NimBus Robot.exe) from the UIM home page.
  3. Run the robot installer on the computer to install the robot. Provide information about the required secure hub to which you want to add the robot.
  4. Deploy the latest robot (7.97 or later).
  5. (For 20.3.3 and later) Follow the instructions in the Secure Transmission of Certificates article to securely transfer the certificates from the hub to the robots pointing to the hub.
  6. (Prior to 20.3.3) On the secure tunnel server, use the robot certificate callback and generate the robot certificate package, if not already done. Deploy the robot certificate package to the robot computer.
  7. Deploy the latest secure robot to the robot computer.
    Non-secure robot is now converted to a secure robot.
Add a Robot Using a Non-Secure Secondary Hub
You can use a non-secure secondary hub in your secure environment to add a new robot.
For Linux, you must have a non-secure secondary hub in your secure setup. Also, ensure that the required package (install_LINUX_23_64) is already available in the non-secure secondary hub archive.
Follow these steps:
  1. Download the robot installer (nimldr or NimBus Robot.exe) from the UIM home page to the computer that you want to add as a robot.
  2. Run the robot installer on the computer to install the robot. Provide information about the required non-secure secondary hub during the robot installation.
    The following example screenshot shows that the nimldr is executed successfully and deploys the new robot:
    rob3 - Copy.PNG
  3. Deploy the latest robot.
    The following example screenshot shows that the non-secure robot is successfully deployed to the new robot computer:
    rob4 - Copy.PNG
  4. Move the robot to the appropriate secure hub in your environment.
    The secure hub must be able to communicate with the non-secure robot because of the presence of hub_adapter on the secure hub.
    The following example screenshot shows that the new robot is successfully moved to the secure hub:
    rob5 - Copy.PNG
  5. On the secure tunnel server, use the robot certificate callback and generate the robot certificate package, if not already done.
  6. (For 20.3.3 and later) Follow the instructions in the Secure Transmission of Certificates article to securely transfer the certificates from the hub to the robots pointing to the hub.
  7. (Prior to 20.3.3) Deploy the robot certificate package to the robot computer.
  8. Deploy the latest secure robot to the robot computer.
    Non-secure robot is now converted to a secure robot.
Add a Robot Using UMP/OC
In this scenario, you use UMP/OC in your secure environment to add a robot. Ensure that the hub_adapter probe is active on the secure hub. This allows the secure hub to communicate with the non-secure robot.
Follow these steps:
  1. In your secure environment, log in to OC.
  2. Start the Discovery Wizard and locate the device that you want to convert to a secure robot.
  3. Select the device and deploy the latest non-secure robot.
    The non-secure robot is deployed in the secure setup and is visible in IM and Admin Console.
  4. (For 20.3.3 and later) Follow the instructions in the Secure Transmission of Certificates article to securely transfer the certificates from the hub to the robots pointing to the hub.
  5. (Prior to 20.3.3) On the secure tunnel server, use the robot certificate callback and generate the robot certificate package, if not already done. Deploy the robot certificate package to the robot computer.
  6. Deploy the latest secure robot to the robot computer.
    Non-secure robot is now converted to a secure robot.
Add a Robot Using an XML File
In this scenario, you use an XML file in your secure environment to add a robot. Ensure that the hub_adapter probe is active on the secure hub. This allows the secure hub to communicate with the non-secure robot.
Follow these steps:
  1. In your secure environment, ensure that the latest automated_deployment_engine (ade) probe is running on the secure primary hub.
  2. Navigate to the
    <Nimsoft>\probes\service\automated_deployment_engine
    folder.
  3. Create an XML file and provide all robot-related details (for example, user name, password, computer details, hub information).
  4. Save the file with the name as host-profiles.xml in the
    <Nimsoft>\probes\service\automated_deployment_engine
    folder.
    The ade probe checks the XML file and deploys the non-secure robot. The non-secure robot becomes visible in IM and Admin Console.
  5. (For 20.3.3 and later) Follow the instructions in the Secure Transmission of Certificates article to securely transfer the certificates from the hub to the robots pointing to the hub.
  6. (Prior to 20.3.3) On the secure tunnel server, use the robot certificate callback and generate the robot certificate package, if not already done. Deploy the robot certificate package to the robot computer.
  7. Deploy the latest secure robot to the robot computer.
    Non-secure robot is now converted to a secure robot.
An example of an XML file is as follows:
<hosts> <host> <profile>Windows</profile> <arch>64</arch> <hostname>10.xxx.xxx.xxx</hostname> <username>Administrator</username> <password>in#4572</password> <domain>uimser01_domain</domain> <hubip>10.xxx.xxx.xxx</hubip> <hub>uimser01_hub</hub> <hubrobotname>uimser01</hubrobotname> <hubport>48002</hubport> <robotname>talsec_robot</robotname> <tempdir>c:\tmp</tempdir> </host> </hosts>
Add a New Hub to a Secure Environment
If you want to add a new hub to a secure environment, you can use the appropriate method depending on your requirements:
  • Add a New Hub Without  Using a Non-Secure Secondary Hub
  • Add a New Hub Using a Non-Secure Secondary Hub
Add a Hub Without Using a Non-Secure Secondary Hub
You can directly add a hub to the secure setup.
This procedure is not applicable to Linux. For Linux, you must have a non-secure secondary hub in your secure setup. Therefore, for Linux, see the Add a New Hub Using a Non-Secure Secondary Hub section.
Follow these steps:
  1. Download the secondary hub installer (NimBUS Infrastructure.exe) from the UIM home page to the system that you want to add as a hub.
  2. Run the installer to install the secondary hub on the system. Provide the domain name to which you want to add this hub.
  3. Copy the tunnelsetup.exe utility and the client certificate from the secure tunnel server. The tunnelsetup.exe utility is available in the
    ..\Nimsoft\hub
    folder. The client certificate is available in the
    ..Nimsoft\hub\certs
    folder.
  4. Run the tunnelsetup.exe on the new hub and provide all the details (for example, tunnel server IP, UIM administrator credentials, and certificate path).
    An example screenshot is as follows:
    tunnelset.exe.png
    Alternatively, you can use IM on this new hub to make it a tunnel client of the secure tunnel server. To do so, you copy the certificate from the secure tunnel server and create a tunnel client certificate on the new hub.
  5. Open the hub configuration, navigate to the
    Status
    tab (
    Tunnel Status
    section) and verify that the tunnel connection is up and running.
    The new non-secure hub is now listed in the domain.
  6. Follow the usual steps (as explained earlier) to bring the new hub to a secure state depending on your scenario:
    1. Deploy hub_adapter to the new hub.
    2. Deploy the latest robot to the new hub.
    3. Deploy the latest secure hub to the new hub.
    4. Deploy the robot certificate package to the robot.
    5. Deploy the latest secure robot to make it a secure robot.
    You have successfully added a new hub and secured it.
Add a Hub Using a Non-Secure Secondary Hub
You can add a new hub to a secure setup by using a non-secure secondary hub, which is already present in the secure setup.
For Linux, you must have a non-secure secondary hub in your secure setup. Also, ensure that the required package (install_LINUX_23_64) is already available in the non-secure secondary hub archive.
Follow these steps:
  1. Download the secondary hub installer (nimldr or NimBUS Infrastructure.exe) from the UIM home page.
  2. Run the installer to install the secondary hub on the new system. Provide the required non-secure secondary hub information during the robot installation. For Linux, ensure that you make the new hub a tunnel client during the hub installation.
    The following example snippet shows that nimldr is being used to install the hub as a tunnel client:
    hub2 - Copy.PNG
  3. For Windows, perform the following steps to make the new hub as a tunnel client (already explained in the previous procedure):
    1. Copy the tunnelsetup.exe utility and the client certificate from the secure tunnel server. The tunnelsetup.exe utility is available in the
      ..\hub
      folder. The client certificate is available in the
      ..\hub\certs
      folder.
    2. Run the tunnelsetup.exe on the new hub and provide all the details (for example, tunnel server IP, UIM administrator credentials, and certificate path).
    For Linux, the new hub is made the tunnel client during the hub installation.
  4. Open the hub configuration, navigate to the
    Status
    tab (
    Tunnel Status
    section) and verify that the tunnel connection is up and running.
    The following example screenshot shows the successful tunnel communication between the new hub (talki-robo2) and the secure primary hub:
    hub5 - Copy.PNG
  5. Follow the usual steps (as explained earlier) to bring the new hub to a secure state depending on your scenario:
    1. Deploy hub_adapter to the new hub.
    2. Deploy the latest robot to the new hub.
    3. Deploy the latest secure hub to the new hub.
    4. Deploy the robot certificate package to the robot.
    5. Deploy the latest secure robot to make it a secure robot.
    You have successfully added a new hub and secured it.
Converting Back to a Non-Secure Mode
To revert your secure environment to the non-secure state, you must downgrade all the robots and hubs in your secure environment by downloading and installing an older version of the robot and hub from the archive. Based on your setup, you can downgrade robots and hubs as follows:
  1. If your secure environment consists of standalone robots that are connected to a secure hub, then you must first downgrade all the standalone robots to an older version that you downloaded from the archive.
  2. After you downgrade standalone robots, downgrade the robots running on the secure hub to an older version that you downloaded from the archive.
  3. After you downgrade all the robots, downgrade the hubs to an older version that you downloaded from the archive.
Enable CABI and OC to Communicate Securely from Separate Secure Robots
To enable CABI and OC to communicate securely from separate secure robots, follow these steps:
  1. Whitelist the IP subnets where UMP and cabi are running by using the existing probe administration UI in IM.
    This configuration ensures that the secure bus understands that wasp and CABI on these subnets can be trusted by the bus.
    UMP CABI Communication 01.png
  2. Using Probe Utility, use the hubsec_setup_put callback on the primary hub to add the IPs of the UMP/OC robot and CABI robot as “trusted_ips” in the security.cfg file of the hub. Use a comma-separated list.
    This configuration ensures that the secure bus understands that these are special robots, and user logins from these robots must be allowed without downgrading access.
    UMP CABI Communication 02.png
  3. Restart the primary hub, restart OC, wait until OC is fully up, and then restart CABI.
Known Issues
The following are the secure hub- and robot-related known issues:
  • The ppm probe provides functionality for the Admin Console probe configuration UIs. The ppm probe does not run on AIX hubs. To configure robots and probes on AIX hubs, use the Raw Configure utility in Admin Console, or use Infrastructure Manager.
  • If the communication with a robot fails in Linux, review your network configuration:
    1. Check for a valid entry for the local system in the
      /etc/hosts
      file for a robot, hub, server, or OC system
    2. The entry for the local system must be a fully qualified hostname and IP address.
    3. If only the loopback address is defined, for example, localhost 127.0.0.1, the controller is unaware of its own IP address.
    4. IP address problems result in network communication failure.
  • The automated_deployment_engine robot distribution to Windows targets sometimes fails to activate the hdb and spooler probes. To resolve the issue, do a validate security on the affected probes (hdb and spooler)
  • If robots are added to the inventory by automated discovery, OC cannot auto-deploy the robots to AIX or z/Linux systems. Use one of the following alternative methods:
    1. Run the native installer manually or with a third-party tool. See Deploy Robots in Bulk with a Third-Party Tool and Native Installers.
    2. Use the automated_deployment_engine (ade) probe with an XML file. See Deploy Robots with an XML File and the ADE Probe.
    3. Import an XML file in OC. See Deploy Robots with an XML File in OC.
  • In a secure environment, if any probe that is installed on an independent secure robot tries to subscribe to queues in the related secure hub, the probe fails to attach to the queues. As a workaround, if the probes require to read or publish to a hub queue, then deploy the probe to the primary hub robot.
  • If you rename the package name in the archive and try to deploy the package to the hub after logging into the same hub, an unexpected error can appear. However, deployment is completed without any issue. For example, if you rename the robot_update package in the archive and try to deploy it to the hub after logging into that hub, you get the following error:
    Aborted, retry limit exceeded, unknown status
    , but the deployment completed successfully.
  • In a
    non-secure to secure
    upgrade, when you deploy the new hub_secure or robot_update_secure packages, an error message is shown that states that the deployment has been aborted. However, the deployment completes without any issue. If you receive this error, you can ignore it.
  • distsrv 9.20 has a dependency on robot 9.20/9.20S. During an upgrade, when you try to deploy distsrv before the robot deployment, an error message is displayed stating that the existing robot version is lower than 9.20/9.20S. This error message does not display the suffix "S" in the robot version if the robot package is a secure one. It simply displays the version without "S", which is misleading. The following error is displayed: Dependency check error: Robot version >=9.20 is required (7.97 found)
Additional Information
  • Manual Upgrade Process
    If you do not upgrade to secure hub and robot using the upgrade installer (UIM Server) and want to do it at a later stage, you can follow the manual process. However, we recommend that you use the upgrade installer as it automatically performs various tasks and significantly eases the secure upgrade process. For more information about how to perform these manual steps to upgrade to secure hub and robot, follow the information documented in Manually Upgrade to Secure and Hub.
  • Troubleshooting
    To review various troubleshooting topics, see the Troubleshooting Secure Hub and Robot article.