|
1. System Administration with iTivity
This chapter provides technical information for administrators to help you understand, plan, and deploy the iTivity software. 1.1 Encryption
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, FTP, chat, TELNET, remote control, and help desk requests are all safely encrypted. 1.2 Authentication
1.2.1 Authentication LevelsTwo levels of authentication are supported for iTivity connections, both of them configurable. As shown in Figure 3, when attempting to access an iServer, a user of iTivity iManager must authenticate against the iServer (1). Then, when attempting to open a connection to view an iAgent computer attached to the iServer, the user can be required to authenticate a second time for that individual iAgent computer (2). Note: No authentication is required by an iAgent connecting to the iServer.
Figure 3: iTivity Authentication Levels 1.2.2 Supported Authentication MethodsBoth authentication levels support these methods on Windows systems: · NTLM · LDAP · Simple Password · No Authentication Required On UNIX/Linux systems, authentication is controlled by system user name and password. The UNIX/Linux permission group is controlled by the iServer and Unattended iAgent configuration files. See Section 2.9, Configuring the iServer on Linux, and Section 8.4, Configuring the Unattended iAgent on UNIX/Linux. 1.2.3 Authentication Strategies for the iServerConsider the information in this section when deciding on the authentication method to use for your iServer. Note: This section discusses iServer authentication on Windows. For information on the Linux iServer, see Section 2.9, Configuring the iServer on Linux. Why Use Authentication for the iServer?
Tridia recommends requiring authentication on the iServer because iTivity iManager displays sensitive information when it connects to an iServer.
This information includes user names, computer IP addresses, operating system versions and so on. All of this information could potentially be useful to hackers. NTLM and LDAP
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 iServer), a Windows user group called iTivityServerUsers is created. Administrators can then add users to this group to allow them access to the iServer. Later, by removing a user or users from the iTivityServerUsers group, the administrator can render that user incapable of connecting to the iServer. Since iAgent computers can only be viewed through an iServer, they are protected from unauthorized remote viewing. For Windows networks, Tridia 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 iServer. By adding or removing users or nested groups, you can easily and centrally control which LDAP users have permission to access iAgent systems via the iServer. Simple Password
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 iServer and reload the iServer Settings. (You can reload the settings on the iServer by choosing Start > All Programs > iTivity > iServer > Administrative Tools > Reload iServer Changes.) No Authentication Required
This option is provided for rare cases when an administrator might decide it is advantageous to allow access to the iServer without authenticating. 1.2.4 Authentication Strategies for iAgent ComputersConsider the information in this section when deciding on the authentication method to use for iAgent computers. An iAgent computer is a machine with one of the iTivity iAgents installed. An iAgent computer must be connected to an iServer in order for it to be viewable by users of the iTivity iManager. Various authentication strategies are available on Windows. Tridia recommends that a uniform authentication policy be established by the system administrator, to make it easy to remember and enforce. For UNIX/Linux systems, Unattended iAgent authentication is controlled by system user name and password. The permission group is controlled by the Unattended iAgent configuration file. See Section 8.4, Configuring the Unattended iAgent on UNIX/Linux. NTLM and LDAP
The advantage of NTLM and LDAP is their use of a central user database. · Under NTLM, each iAgent type has its own permission group. By default the Unattended iAgent uses iTivityUnattendedUsers and the Attended iAgent 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 iAgent through iTivity iManager. One critical issue to keep in mind when using NTLM or LDAP for iAgent authentication is the context of the iAgent computer. The authentication server used by the iAgent 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 iAgent system. Simple Password
With the Simple Password method, each iAgent computer has its own password, whether unique or otherwise. Administrators might choose the Simple Password method for iAgent 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 iManager. · 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 iAgent computer. No Authentication Required
Finally, the No Authentication Required option might be chosen to make iAgent computers more quickly accessible for viewing, provided that these computers do not require a secure login. Tridia does not recommend this option except in rare special circumstances. Using Multiple Authentication Methods
Another strategy is to use different authentication methods for different iAgent 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. 1.2.5 Advanced AuthenticationStarting with iTivity version 4.6, administrators can implement a more detailed security scheme. By setting up permission groups on the iServer and corresponding support domains on iAgent computers, you can limit users of iTivity iManager to viewing only a subset of the iAgents connected to your iServer. You can also precisely define the level of permissions these users have. For complete information on advanced authentication, see the iTivity Deployment Guide. 1.3 Configuring the iServer on the Network
1.3.1 Server SelectionThe iServer 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 iServer software on a system that is already experiencing heavy CPU or I/O loads will cause remote control sessions to respond too slowly. 1.3.2 iServer PlacementSome customers choose to set up the iServer 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 iServer 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 iAgents and iTivity iManager users must specify the public IP address of the firewall instead of the private IP address of the iServer system. 1.3.3 Port ConfigurationIn order for the iServer to be accessed and used via the Internet, there must be publicly visible Internet access to one or both of the connection ports. · The iAgent registration port allows iAgent systems to register themselves with the iServer for remote access. It defaults to TCP port 23800. · The remote user view port allows iTivity iManager users to view and control iAgent computers. This port defaults to TCP port 25800. If only the iAgent registration port is accessible to the Internet, then iTivity iManager users can view iAgents over the Internet, but they themselves must be located on the iServer’s local network. If only the remote user view port is accessible to the Internet, then iTivity iManager users can connect from anywhere, but they can only access iAgent systems that reside on the same local network as the iServer. To allow both iAgents and iTivity iManager users to connect from anywhere, configure both ports to be accessible via the Internet. Changing the iAgent Registration Port for Added Security
For those customers deploying the iTivity iAgents into end-user environments with tight security restrictions, it may be helpful to change the iAgent 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 iServer configuration (on Windows: HKLM\Software\Tridia\iTivity\connector_ia\iasServerPort) · The iAgent software setup, via the installation setting “varItivityConnectPort”. See Section 5.4, Editing the iAgent HTML Files for information. If these settings do not match, then the iAgent system will not be able to register and therefore will not appear in the iServer’s list of connected computers in the iTivity Manger. If the iServer is positioned behind a firewall, then the port forwarding must accept the iAgent registration from port 443 on the public IP address of the firewall. 1.4 Using Web-based installation
1.4.1 Distributing iAgents via E-MailOne of major advantages of iTivity is the ease of deployment of the iTivity iAgents. Through web-based, one-click install, system administrators can easily deploy the Attended iAgent and Unattended iAgent onto as many Windows computers as needed. First, install the iAgents 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 iAgents will work, simply by editing parameters in the delivered HTML files. This can include having the iAgent immediately connect to your specific iServer. See Section 5.4, Editing the iAgent HTML Files, for information. Or, as an alternative, build custom installers for the iAgents on the Tridia 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 iAgents 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 iAgent 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 iAgent is installed automatically. 1.4.2 Other Distribution OptionsEmail is not the only means of deployment. Administrators can also create their own web pages that in turn point to an iTivity iAgent 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 iAgent 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 iAgents by copying the installation files over the local network. 1.5 iTivity iManager
The iTivity iManager provides the main user interface for administrators and support personnel. The iManager main window displays the configured iServers and any iAgent computers currently connected to them. While some organizations have only one iServer on their network, the iTivity iManager can connect to and list any number of iServers.
iTivity iManager stores its list of iServers in a .ncn file. You can add all of your iServers to this file, or you can have multiple files with different sets of iServers. By default, the iManager 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 iManager to share the same iServer list. A key feature of iTivity iManager is the Windows Explorer-like interface in the left pane of the main window. When you connect to an iServer, the list expands to show all iAgent computers currently connected to that iServer.
Also the right pane is populated with more detailed information about each registered iAgent computer, such as the operating system version, release number, service pack, etc. This information can be of value to a diagnostician attempting to solve a problem.
Similar information for an iAgent computer is available by right-clicking on the computer in the list and choosing Properties from the popup menu. When using the iManager, remember to select the iServer or connected iAgent computer in the left pane. The menu and tool bar options generally act on the selected item. For complete instructions on the iTivity iManager interface and features, see Chapter 4, Using iTivity iManager. 1.5.1 Configuring iTivity WebTunnelBeginning with iTivity v 5.2, the iTivity WebTunnel feature extends the viewing and remote control capabilities of iManager. WebTunnel discovers available network applications running on a connected iAgent computer and provides remote access to those applications through an encrypted SSL connection. When an iAgent is connected to an iManager, you can see the network applications that are available to that iAgent system. WebTunnel works for both Windows and UNIX/Linux iAgent systems. iTivity WebTunnel 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 iAgent to scan and report additional HTTP, HTTPS, RDP, VNC and Telnet based applications. How iTivity WebTunnel Works
The iAgent software scans the TCP ports on the iAgent computer. When an active TCP port is detected, the iAgent 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 iManager sees the tunneled applications in the list, under the name of the connected iAgent. The user can double-click a tunneled application to begin a remote access session. In most cases, a web browser opens on the iManager computer to provide an interface to the web application over iTivity’s secure connection. In the example below, three tunneled applications are displayed in iManager, indicated by the globe icon.
Default Application Scan List
The table shows the default application scan list and ports for Windows and UNIX/Linux iAgents.
Adding Network Applications to the Scan List
For both Windows and UNIX/Linux iAgents, you can customize the scan list to add network applications and make them viewable in iManager. Windows ApplicationsThe list of applications an iAgent scans for is found in the Windows system registry.
To add custom applications to the list, do the following: 1. Create a new registry key: HKEY_LOCAL_MACHINE\Software\Tridia\iTivity\processor_od\ 2. Create the following registry values under the new customAppScan_1 key:
3. After adding the custom registry updates, restart the iTivity iAgent to allow the scan to detect the custom applications. UNIX/Linux ApplicationsThe list of applications a UNIX/Linux iAgent scans for are defined in the iTivity iAgent configuration file. The default path and filename is /etc/iTivity/iAgent.conf 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 iAgent for the changes to take effect.
Example iAgent.conf file settings This set of entries adds a web application called Acme Accounting Ace to the iAgent scan list.
1.6 Help Desk Window
The Help Desk window is launched from the iTivity iManager main window. With the Help Desk, administrators can easily monitor the help queue and provide help to any user at any time.
1.6.1 Using the Help Desk WindowThe Help Desk window can be used by both support personnel and managers. When you open the window it displays all users who have requested help. When their requests for help are answered, the users are automatically removed from the list. By observing the date and time help requests came in, a Help Desk manager can keep track and make sure that all requests are serviced in a timely fashion. 1.6.2 Using Announcement and Help GroupsThe Help Desk feature uses the concept of Announcement’ and of help groups or 'Support Domains'. A support person can open the Help Desk window and ‘announce’ that he or she is ready to provide help. By filling in a Support Domain on the Announce Help dialog, the support person indicates that they belong to a specific help desk group. For example, a help desk manager could decide to assign team members to an ‘Accounting Help Desk’ group and a ‘Marketing Help Desk’ group. Users in the accounting department could then be instructed to request help only from members of the Accounting Help Desk group.
Copyright © 2017 - 2023, iTivity Corporation |
