|
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 iManager 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 on Windows systems: · 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. 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 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 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 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 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 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 iManager. 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 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 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.2.5 Advanced Authentication Using Permission Groups and Support DomainsStarting 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 agent computers, you can limit users of iTivity iManager to viewing only a subset of the agents connected to your iServer. You can also precisely define the level of permissions these users have. Example: Your organization has offices in Georgia and Texas and there are agent computers at both sites connected to your iServer. You want the support team in each state to be able to view only the agent computers located at their site. You can accomplish this by defining support domains called GA and TX on the agent computers and using permission groups on the iServer. Supported
Platforms
Currently, advanced authentication is supported on Windows iServers (using NTLM authentication) and on Linux iServers. Global Access is
the Default
Global access to all iServer agents is the default. That is, if you do not specify support domains as explained in this section, all users who successfully authenticate on the iServer will be able to see and control all connected agents. Implementation
Overview
Implementing advanced authentication involves these steps: 1. Create security groups on the iServer and add users to those groups. 2. Create additional security groups to serve as permission groups using group names specified in the Registry (on Windows iServers) or iServer.conf file (on Linux iServers). 3. Add the security groups defined in Step 1 to the permission groups defined in Step 2. 4. Define support domains for the agent computers. These domains correspond to the permission groups defined in Step 2. Result: After these steps have been completed, an iManager user can enter his support domain when authenticating against the iServer. This will establish his permission group and determine which agents he can see and control. Step 1: Create
the User Accounts and Security Groups
The first step is to create security groups for the iServer and add user accounts to those groups. Use the standard method for creating users and groups for either the Windows (NTLM) or Linux platform. Example: Using the example situation, you would define groups called TX and GA and add the appropriate users to those groups. You would also define a group called Administrators to allow iServer administrators to have global access. Step 2: Define
the Permission Groups
The next step is to create additional security groups to serve as permission groups. The permission groups must be named according to entries listed in the Windows Registry or the Linux iServer.conf file. The iServer recognizes two sets of permission group values. The first is for agents connected to the iServer via the Internet and the second is for agents connected using the secure dial up feature. Note: For more information on secure dial up, contact Tridia technical support.
The default permission groups for the iServer are shown below. In the Windows Registry, these entries are defined by the key HKLM\Software\Tridia\iTivity\Processor_ia.
Example: To implement security for the example situation, you could use the default Registry entries as follows. · Create a security group called iServerStaff. · You already have a group called Administrators as defined in Step 1. Step 3: Add the
Security Groups to the Permission Groups
Next, you add the security groups defined in Step 1 to the permission groups defined in Step 2. Example: For the example situation. · Add the groups TX and GA created in Step 1 to the group called iServerStaff. · The Administrators group already contains the user accounts for the iServer administrators. Result: · iManager Users in the Administrators group will have full permissions on the iServer. · iManager users who are in the TX and GA user groups will have the permissions defined by the following keywords: ListIASDBPermGroup, AccessIASDBPermGroup, ListOUTDBPermGroup, and AccessOUTDBPermGroup. That is, these users will be able to see and control agents but not close their connections to the iServer or modify the database. Which agents they can see and control will be determined by the support domains on the agents, as discussed in Step 4. Step 4: Define
the Agent Support Domains
When you install the Admin Agent or Live Support Agent, you have the option of declaring one or more support domains for that particular agent computer. Used in combination with permission groups, support domains define which agents a user of iManager can view and control. For information on specifying support domains for an agent computer, see Section 5.3 Editing the Agent HTML Files and Section 5.5, Installing the Admin Agent or Live Support Agent From the Distribution EXE. When an iTivity iManager user attempts to connect to an iServer in an organization that uses support domains, they must enter the support domain in the Authentication dialog.
Example: To complete the example discussed in Steps 1, 2 and 3: When installing agent software in the Georgia office, you would define the support domain as GA. When installing agents in the Texas office, you would define support domain TX. Result: iManager users in the GA permission group will declare GA as their support domain when connecting to the iServer. They will then be able to see and control the agents residing in Georgia. Similarly, users in the TX group will declare TX as their support domain and be able to see and control the agent systems in Texas. How Support Domains Are AuthenticatedThe support domain entered by a user matches the agent's support domain when they are exactly the same or when the user's support domain is shorter and matches the suffix of the agent's support domain. The following table shows some examples of matches and non-matches:
Example: Consider three different agent systems declaring the following support domains: A- 8642.GA.US B- 7531.GA.US C- 5678.TX.US · For an iManager user to declare the US support domain and gain access to all three of these agents, there must exist on the iServer a security group named US. · For an iManager user to declare the GA.US support domain and gain access to only systems A and B, there must exist a group on the iServer named GA.US. · For an iManager user to declare the TX.US support domain there must exist a group named TX.US on the iServer. · If there was a need to access just the B agent shown above, then a permission group named 7531.GA.US could be created. 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 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 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 iManager 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 iManager 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 iManager 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 iManager 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 (on Windows: 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 iManager
The iTivity iManager provides the main user interface for administrators and support personnel. The iManager 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 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 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 iManager, 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 iManager interface and features, see Chapter 4, Using iTivity iManager. 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 © 2004 - 2005, Tridia
Corporation |
