|
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 1024 bit RSA asymmetric key exchange with 3DES bulk encryption (56 * 3 = 168 bit symmetric). When a connection is first established, the key exchange takes place and is done with every 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 Manager must authenticate against the iServer (1). Then, when attempting to open a connection to view an agent computer attached to the iServer, 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 iServer.
Figure
3: iTivity Authentication Levels 1.2.2 Supported Authentication MethodsBoth authentication levels support these methods: · NTLM · LDAP · Simple Password · No Authentication Required On Linux/UNIX systems, authentication is controlled by system user name and password. The Linux/UNIX permission group is controlled by the iServer and Admin Agent configuration files. See Section 2.9, Configuring the iServer on Linux, and Section 8.3, Configuring the Admin Agent on Linux/UNIX. 1.2.3 Authentication Strategies for the iServerConsider the information in this section when deciding on the authentication method to use for your iServer. Why Use
Authentication for the iServer?
Tridia recommends requiring authentication on the iServer because iTivity Manager 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 of 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 agent 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 agent 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 > Programs > iTivity > Administrative Tools > Reload iTivity 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 Agent ComputersConsider the information in this section when deciding on the authentication method to use for agent computers. An agent computer is a Windows machine with either the Live Support Agent or Admin Agent installed. An agent computer must be connected to an iServer in order for it to be viewable by users of the iTIvity Manager. Various authentication strategies are available. Tridia recommends that a uniform authentication policy be established by the system administrator, to make it easy to remember and enforce. For Linux/UNIX systems, Admin Agent authentication is controlled by system user name and password. The permission group is controlled by the Admin Agent configuration file. See Section 8.3, Configuring the Admin Agent on Linux/UNIX. NTLM and LDAP
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 Admin Agent uses iTivityAdminUsers and the Live Support Agent uses iTivitySupportUsers. · 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 usergroup (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 Manager. 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. Simple Password
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 Manager. · 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. No
Authentication Required
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. 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 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. 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 agents and iTviity Manager 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 agent registration port allows agent systems to register themselves with the iServer for remote access. It defaults to TCP port 23800. · The remote user view port allows iTivity Manager 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 Manager users can view agents 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 Manager users can connect from anywhere, but they can only access agent systems that reside on the same local network as the iServer. To allow both agents and iTivity Manager users to connect from anywhere, configure both ports to be accessible via the Internet. Changing the
Agent Registration Port for Added Security
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 iServer configuration (HKLM\Software\Tridia\iTivity\connector_ia\iasServerPort) · The agent software setup, via the installation setting “varItivityConnectPort”. See Section 4.3, 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 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 agent registration from port 443 on the public IP address of the firewall. 1.4 Using Web-based installation
1.4.1 Distributing Agents via E-MailOne 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 Live Support Agent and/or the Admin 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 4.2. 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 iServer. Refer to Section 4.3, Editing the Agent HTML Files, for information. After the agents are configured for deployment from a web 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. 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 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, in you are supporting computers without e-mail or web access, you can install the agents from CD ROM or by copying the installation files over the local network. 1.5 iTivity Manager
The iTivity Manager provides the main user interface for administrators and support personnel. The Manager's main window displays the configured iServers and any agent computers currently connected to them. While many organizations have only one iServer on their network, the iTivity Manager can connect to and list any number of iServers.
iTivity Manager 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 Manager 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 Manager to share the same iServer list. A key feature of iTivity Manager is the Windows Explorer-like interface in the left pane of the main window. When you connect to an iServer, th the list expands to show all agent computers currently connected to that iServer.
Also the right pane is populated with more detailed information about each registered agent compute, 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 agent computer is available by right-clicking on the computer in the list and choosing Properties from the popup menu. When using the Manager, remember to select the iServer or connected agent computer in the left pane. The menu and tool bar options generally act on the selected item. For complete instructions on the iTivity Manager interface and features, see Chapter 4, Using iTivity Manager. 1.6 Help Desk Window
The Help Desk window is launched from the iTivity Manager 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 © 2004, Tridia
Corporation |
