-This chapter provides technical information for administrators to help you understand, plan, and deploy the iTivity software.
All connections between the iTivity components are encrypted at all times, unless configured otherwise by the system administrator. The encryption used is 2048 bit RSA asymmetric key exchange with AES encryption using 256 bit bulk/session/symmetric keys.
When a connection is first established, the key exchange takes place and is done with a high level of security. Once the key exchange takes place, a lower (yet secure) encryption level is used in order to permit fast communication.
With the secure connection in place, all communications and functions are all safely encrypted.
Two levels of authentication are supported for iTivity connections, both of them configurable.
As shown in Figure 3, when attempting to access a hyperserver, a user of the console must authenticate against the hyperserver (1). Then, when attempting to open a connection to view an agent computer attached to the hyperserver, the user can be required to authenticate a second time for that individual agent computer (2).
Note: No authentication is required by an agent connecting to the hyperserver.
Both authentication levels support these methods on Windows systems:
No Authentication Required
On Linux systems, authentication is controlled by system user name and password. The Linux permission group is controlled by the hyperserver and unattended agent configuration files. See Section 2.9, Configuring the hyperserver on Linux, and Section 8.4, Configuring the unattended agent on Linux.
Consider the information in this section when deciding on the authentication method to use for your hyperserver.
Note: This section discusses hyperserver authentication on Windows. For information on the Linux hyperserver, see Section 2.9, Configuring the hyperserver on Linux.
iTivity recommends requiring authentication on the hyperserver because the console displays sensitive information when it connects to the hyperserver.
This information includes user names, computer IP addresses, operating system versions and so on. All of this information could potentially be useful to hackers.
Both NTLM and LDAP provide a centralized user database. These authentication methods support permission groups that allow access to be granted precisely to one or more users or groups. Having a central user database can be a great advantage when managing staff turnover.
When NTLM is selected as the authentication method (during installation of the hyperserver), a Windows user group called iTivityServerUsers is created. Administrators can then add users to this group to allow them access to the hyperserver. Later, by removing a user or users from the iTivityServerUsers group, the administrator can render that user incapable of connecting to the hyperserver. Since agent computers can only be viewed through a hyperserver, they are protected from unauthorized remote viewing. For Windows networks, iTivity Corp recommends NTLM for this reason.
Under LDAP, the permission group is specified through the ldapGroupURL or authorization group object. This LDAP object is a group containing users or groups that are allowed to access the hyperserver. By adding or removing users or nested groups, you can easily and centrally control which LDAP users have permission to access agent systems via the hyperserver.
As the name implies, the Simple Password authentication method has the advantage of simplicity. For administrators who feel they have a secure environment or do not have an NTLM or LDAP background, the Simple Password may be chosen.
A possible drawback to using Simple Password is when staff changes occur. An administrator must then change the password on the hyperserver and reload the hyperserver Settings. (You can reload the settings on the hyperserver by choosing Start > All Programs > iTivity > iServer > Administrative Tools > Reload iServer Changes.)
This option is provided for rare cases when an administrator might decide it is advantageous to allow access to the hyperserver without authenticating.
Consider the information in this section when deciding on the authentication method to use for agent computers.
An agent computer is a machine with one of the iTivity agents installed. An agent computer must be connected to a hyperserver in order for it to be viewable by users of the iTivity console.
Various authentication strategies are available on Windows. iTivity recommends that a uniform authentication policy be established by the system administrator, to make it easy to remember and enforce.
For Linux systems, unattended agent authentication is controlled by system user name and password. The permission group is controlled by the unattended agent configuration file. See Section 8.4, Configuring the unattended agent on Linux.
The advantage of NTLM and LDAP is their use of a central user database.
* Under NTLM, each agent type has its own permission group. By default the unattended agent uses iTivityUnattendedUsers and the attended agent uses iTivityAttendedUsers.
* Under LDAP, users are defined by the ldapGroupURL object.
With the central database, administrators can quickly prevent users from viewing computers remotely simply by removing them from the relevant user group (in NTLM) or object (LDAP). For example, if a user is no longer with the organization, or is no longer assigned to a help desk role, the administrator can go to the Domain Controller and remove that user from the permission group. The individual will no longer be able to view any agent through iTivity console.
One critical issue to keep in mind when using NTLM or LDAP for agent authentication is the context of the agent computer. The authentication server used by the agent computer will likely be local to that system. Therefore, the remote user will need a user id and password that is valid for the authentication context (domain or directory) of the agent system.
With the Simple Password method, each agent computer has its own password, whether unique or otherwise. Administrators might choose the Simple Password method for agent authentication for several reasons:
You might want to give the end user control over who can connect to their computer, by having them set their own Simple Password. Of course, the administrator or help desk user will have to be told what the password is before they could connect through iTivity console
The Simple Password method offers the advantage of simplicity. Also it might be preferred by an administrator who does not have an NTLM or LDAP background or does not have domain controllers or an LDAP server on the network.
VARs (Value Added Resellers) might choose Simple Password if they need to support many users at widely dispersed locations. In this case, the NTLM or LDAP methods may be too difficult to implement. Or if the supported users work for different organizations, those organizations probably would not want to share authentication information. Note that it is perfectly possible for remote offices to use NTLM or LDAP. The NTLM or LDAP authentication server would simply have to reside on the same network as the agent computer.
Finally, the No Authentication Required option might be chosen to make agent computers more quickly accessible for viewing, provided that these computers do not require a secure login. iTivity Corp does not recommend this option except in rare special circumstances.
Another strategy is to use different authentication methods for different agent computers.
For example, a group of computers in the Accounting Department at a corporate headquarters might be assigned NTLM or LDAP authentication, while computers in remote field offices might use Simple Password. iTivity supports multiple methods to allow system administrators the greatest flexibility in configuring their networks.
Starting with iTivity version 4.6, administrators can implement a more detailed security scheme. By setting up permission groups on the hyperserver and corresponding support domains on agent computers, you can limit users of iTivity console to viewing only a subset of the agents connected to your hyperserver. You can also precisely define the level of permissions these users have.
For complete information on advanced authentication, see the iTivity Deployment Guide.
The hyperserver software can be installed on a dedicated server or on a server already used for other functions. To ensure fast responses (low latency) the software should be installed on a lightly-loaded system or a dedicated server. Installing the hyperserver software on a system that is already experiencing heavy CPU or I/O loads will cause remote control sessions to respond too slowly.
Some customers choose to set up the hyperserver in an area outside the firewall that is directly accessible via the Internet. (This area is often called the DMZ.) Since DMZ systems are also directly accessible from the organization's local network, this option may be the simplest to implement.
The hyperserver can also be placed behind a firewall, as long as port forwarding is enabled for the connection port types needed.
When port forwarding is used, the agents and iTivity console users must specify the public IP address of the firewall instead of the private IP address of the hyperserver system.
In order for the hyperserver to be accessed and used via the Internet, there must be publicly visible Internet access to one or both of the connection ports.
- The agent registration port allows agent systems to register themselves with the hyperserver for remote access. It defaults to TCP port 23800.
-The remote user view port allows iTivity console users to view and control agent computers. This port defaults to TCP port 25800.
If only the agent registration port is accessible to the Internet, then iTivity console users can view agents over the Internet, but they themselves must be located on the hyperserver's local network.
If only the remote user view port is accessible to the Internet, then iTivity consoleusers can connect from anywhere, but they can only access agent systems that reside on the same local network as the hyperserver.
To allow both agents and console users to connect from anywhere, configure both ports to be accessible via the Internet.
For those customers deploying the iTivity agents into end-user environments with tight security restrictions, it may be helpful to change the agent registration port to TCP port 443. This port is more likely to be supported for outbound connections from the end user network.
This change must be implemented in both:
The hyperserver configuration (on Windows: HKLM\Software\Tridia\iTivity\connector_ia\iasServerPort)
The agent software setup, via the installation setting varItivityConnectPort. See Section 5.4, Editing the agent HTML Files for information
If these settings do not match, then the agent system will not be able to register and therefore will not appear in the hyperserver's list of connected computers in the iTivity console. If the hyperserver is positioned behind a firewall, then the port forwarding must accept the agent registration from port 443 on the public IP address of the firewall.
One of major advantages of iTivity is the ease of deployment of the iTivity agents. Through web-based, one-click install, system administrators can easily deploy the attended agent and unattended agent onto as many Windows computers as needed.
First, install the agents to a web server by installing the iTivity Support Module as described in Section 5.3. System administrators can then configure options for how the agents will work, simply by editing parameters in the delivered HTML files. This can include having the agent immediately connect to your specific hyperserver. See Section 5.4, Editing the agent HTML Files, for information.
Or, as an alternative, build custom installers for the agents on the iTivity support site, as explained in Appendix B. You can configure these installers with the options you need and place them on a web or ftp server for users to access.
After the agents are configured for deployment from a web or ftp server, the administrator can simply send an email to all users who need to have a particular agent installed. This email would contain instructions and a link to the proper download file.
When the email is received, the end-user simply clicks the link and the configured iTivity agent is installed automatically.
Email is not the only means of deployment. Administrators can also create their own web pages that in turn point to an iTivity agent deployment page. Users can click on links on these pages and the same installation process takes place as described above.
In an intranet situation, the intranet server might feature a support page. This page could list the different iTivity agent versions available and allow the end-user to choose the one that matches their situation.
Finally, if you are supporting computers without e-mail or web access, you can install the agents by copying the installation files over the local network.
The iTivity console provides the main user interface for administrators and support personnel. The console main window displays the configured hyperservers and any agent computers currently connected to them. While some organizations have only one hyperserver on their network, the iTivity console can connect to and list any number of hyperservers.
iTivity console stores its list of hyperservers in a .ncn file. You can add all of your hyperservers to this file, or you can have multiple files with different sets of hyperservers. By default, the console loads its last used .ncn file.
One good strategy is to store the .ncn file in a network directory. This allows all users of iTivity console to share the same hyperserver list.
A key feature of the console is the Windows Explorer-like interface. When you connect to a hyperserver, the list expands to show all agent computers currently connected to that hyperserver.
Additional information for an agent computer is available by right-clicking on the computer in the list and choosing Properties from the popup menu.
For complete instructions on the iTivity console interface and features, see Chapter 4, Using iTivity console.
The iTivity AppTunnel feature extends the viewing and remote control capabilities of the console.
AppTunnel discovers available network applications running on a connected agent computer and provides remote access to those applications through an encrypted SSL connection. When an agent is connected to a console, you can see the network applications that are available to that agent system. AppTunnel works for both Windows and Linux agent systems.
iTivity AppTunnel supports a number of well-known applications, such as Webmin, SWAT, VNC, RDP, Telnet and CUPS, preconfigured for your convenience. In addition, you can customize the agent to scan and report additional HTTP, HTTPS, RDP, VNC and Telnet based applications.
The agent software scans the TCP ports on the agent computer. When an active TCP port is detected, the agent looks at the list of default applications (and optionally custom applications that you have added). If the discovered port number matches a port number in the application list, iTivity tunnels the application port.
A user running the console sees the tunneled applications in the list, under the name of the connected agent. The user can double-click a tunneled application to begin a remote access session. In most cases, a web browser opens on the console computer to provide an interface to the web application over iTivity's secure connection.
The table shows the default application scan list and ports for Windows and Linux agents.
Standard Web Server (http)
Secure Web Server (https)
Remote Desktop Server (RDP)
AppleShare IP Web Admin
FileMaker Web Application
Dell Web Admin
HP Insight Manager
Ruby Web Application
Powerchute Network Shutdown
Oracle Secure Web Server
VMWare Server Console
VMWare Secure Server Console
Parallels Plesk Control Panel
Websphere Admin Console
Websphere Secure Admin Console
Websphere Application Server
Document Search IMNSearch
For both Windows and Linux agents, you can customize the scan list to add network applications and make them viewable in the console.
The list of applications an agent scans for is found in the Windows system registry.
For This Agent...
Use This Key...
To add custom applications to the list, do the following:
1. Create a new registry key:
2. Create the following registry values under the new customAppScan_1 key:
Required. Specifies the local TCP port number the agent will check for the presence of the application. If there is no program, application or daemon listening on this port, the agent will not report the availability to the console. If a listening program is found, then the application or service is reported back to the console for access by the console user.
Required. Application protocol. Currently supported protocols include, "http", "https", "telnet", "vnc" and "rdp". For web applications, the protocol should be either "http" or "https".
Optional but recommended. Specifies the user readable display name of the application or service. This name should have a clear meaning to the console user.
Example: appname=Standard Web Server
Optional. Some operating systems have platform specific session labels. This setting should declare the session in which the application or service is running, if any. Typical session names would include, "tty0", "pts/4", ":4", "tcp #7", etc. This setting is optional.
Example: session = Service
Specifies the path to the default page or landing page for the application. Typically only used for web/http applications.
3. After adding the custom registry updates, restart the iTivity agent to allow the scan to detect the custom applications.
The list of applications a Linux agent scans for are defined in the iTivity agent configuration file. The default path and filename is
To add a custom application to the scan list, you create a new customAppScan definition in the file. Add the following entries for each application you want to add. After editing and saving the file, restart the agent for the changes to take effect.
Description: Specifies the local TCP port number the agent will check for the presence of the application. If there is no program, application or daemon listening on this port, the agent will not report the availability to the console. If a listening program is found, then the application or service is reported back to the console for access by the console user.
Description: Required. Application protocol. Currently supported protocols include, "http", "https", "telnet", "vnc" and "rdp". For web applications, the protocol should be either "http" or "https".
Example: /appname=Standard Web Server
Description: Optional but recommended. Specifies the user readable display name of the application or service. This name should have a clear meaning to the console user.
Description: Optional. Some operating systems have platform specific session labels. This setting should declare the session in which the application or service is running, if any. Typical session names would include, "tty0", "pts/4", ":4", "tcp #7", etc.
Description: Specifies the path to the default page or landing page for the application. Typically only used for web/http applications.
Example iAgent.conf file settings
This set of entries adds a web application called Acme Accounting Ace to the agent scan list.
# Check for Acme Accounting Ace.
Processor_rc/customAppScan_1/appname=Acme Accounting Ace
Product support is available from iTivity by web site or email:
Copyright © 2004 - 2019, iTivity Corporation Copyright and License Information