|
1. Deploying the iServer
This chapter provides information and recommendations for deploying the iServer software on Windows and Linux systems. 1.1 System Requirements and Recommendations
Windows Hardware and Software
The recommended platform for the iServer on Windows includes the following. In large deployments the iServer computer should be dedicated to running only the iServer software. Hardware· 500 MHz x86 CPU · 64MB RAM · At least a 100Mb network card · At least 10MB free disk space Software· Windows 2003 Server with the latest service packs Note: While other versions of Windows are supported under the minimum requirements, the latest version of Windows 2003 is highly recommended, especially for enterprise-scale deployments. Linux Hardware and Software
The recommended platform for the iServer on Linux includes the following. In large deployments the iServer computer should be dedicated to running only the iServer software. Hardware· 120 MB minimum disk space · 8MB RAM baseline, plus 336 KB per iServer connection · At least a 100Mb network card. · 300 Mhz minimum CPU Note: Active remote control (viewing) sessions use approx. 20 to 100 Mhz each depending on bandwidth and the number of screen updates. Software· Latest version of Red Hat with the latest patches General Requirements and Recommendations
The requirements and recommendations in this section apply to both Windows and Linux versions of the iServer. Typically, resources used by the iServer increase based on the number of connections and Agent sessions. · An Agent connection as used here refers to a connection from an Agent system to the iServer. · An iManager connection refers to a connection from an iManager to the iServer. · An Agent session is defined as an active remote viewing session of an Agent system processed by the iServer at the request of an iManager user. Disk SpaceInstalling the iServer software requires a minimum of 60 MB free disk space. For production environments, 120 MB disk space is considered the minimum requirement. Space required by the activity log is another consideration. Tridia recommends a minimum 2 KB disk space for each Agent session. The log file continues to accumulate space unless purged manually. For best performance in large deployments, ample space and a highspeed disk is recommended, such as any 10KRPM hard drive. CPU CapacityTridia recommends 1 Ghz CPU capacity be dedicated for every 10 simultaneous Agent sessions. The iServer is multithreaded and can take advantage of multiple CPUs in the same server. Systems with hyperthreading are considered to have one CPU per hyperthread. Typically, a single hyperthreaded core provides two separate CPUs. RAM RequirementsRAM requirements on the iServer depend on the number of connecting Agents and iManagers and the number of active sessions between the iManager and Agent systems.
BandwidthThe screen viewing bandwidth in iTivity degrades gracefully when the network becomes congested. That is, iTivity literally uses less bandwidth in the face of higher network congestion. The bandwidth used by iTivity depends on the screen resolution, color depth and exact applications being viewed in each Agent session. Tridia recommends that the iServer be implemented with 64 kbps available bandwidth for each connected iManager user. 1.2 Network Setup
Port Configuration
In 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. Recommendation for the Agent Registration Port
Generally, supporting Agent systems is more challenging. Therefore the best port in practice for Agent connections is port 443. This port is more likely to be supported for outbound connections from the end user network and also provides better security. Note that using this port for the iServer prevents running a secure web server on the same computer. Any change to the Agent registration port must be implemented on both the iServer and the Agent systems. 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 iManager. Note: 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. Setting the Ports on the iServer
WindowsTo change the iServer port configuration on Windows, edit the following Registry keys:
LinuxTo change the iServer configuration on Linux, edit the Ports setting in the iServer.conf file. This file is located in the installation directory of the Linux computer.
Setting the Ports on Agent Systems
Port configuration on Agent systems is controlled by the installation setting “varItivityConnectPort”. You can edit this setting by editing the HTML files that control one-click installation. If installing the Agent from the distribution EXE, you can set the port during the installation process. You can also reset the port after installation, for both the Live Support Agent and Admin Agent. See the iTivity User Guide for more information. 1.3 Advanced Authentication Using Permission Groups and Support Domains
Starting 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 Agents is the default. That is, if you do not specify support domains as explained in this section, all users who are granted permission and successfully authenticate on the iServer will be able to see and control all connected Agents. Note: Default permissions are granted permission via the global access groups: · “iTivityServerUsers” on Windows · “isrvauth” on Linux SUPPORT DOMAIN CONCEPTS
On both Windows and Linux, the security groups mechanism is used to support various security features within iTivity. Security groups are used to implement both iTivity support domain groups and iTivity permission groups. · Support domain groups control which Agents a particular iManager user can interact with. · Permission groups control the type of interaction allowed. Each Agent can declare one or more support domains, which control which users may access that Agent system. Each iManager user can authenticate with the iServer under one or more support domains. This controls the Agents they will see in the iManager and possibly be able to access, based on their permission group memberships. Note: All Active Directory security groups (for both permission groups and support domains groups) must be created with "Domain Local" scope. Do not create Active Directory security groups of "Universal" or "Global" scope for use with iTivity. Implementation Overview
Implementing advanced authentication involves these steps: 1. Create support domain security groups on the iServer 2. Add users to those groups. These uses will be able to access the Agents represented b those support domain groups. 3. 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). 4. Add iManager users to the permission groups to specify the type of Agent access they should be allowed. 5. Configure or deploy iTivity to the Agent computers with settings to specify which support domain(s) each Agent belongs to. These domains have the same name as the support domain security groups defined in Step 1. 6. When logging in to the iManager users specify one or more support domains. The iManager users must be members of the support domain security groups in order to access those Agents. Result: After these steps have been completed, an iManager user can enter his support domain(s) when authenticating against the iServer. This will establish his authenticated support domains(s) and determine which Agents he can see and control. In this way, access control is centralized in the iServer. Step 1: Create the Support Domain Security Groups
The first step is to create support domain security groups for the iServer. 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. Step 2: Create and Add User Accounts
If necessary, create user account(s) for each iManager user. For each support domain you want the iManager user to be able to access, add the user as a member of the security group for that support domain. Example: Add the Georgia-based support staff to the GA security group from Step 1. Add the Texas-based support staff to the TX security group from Step 1. Step 3: 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. · If you wish to allow users other than the built-in Administrators group to administer the iServer, then create a new security group, such as iServerAdmins. Then change the UpdateIASDBPermGroup and AdminIASDBPermGroup settings in the registry to refer to the new group name. Step 4: Add Users to the Permission Groups
Next, add the iManager users to the permission groups for their level of access. Example: For the example situation. · Add the support team members to the group called iServerStaff. · The Administrators group already contains the user accounts for the iServer administrators. If you created the iServerAdmins group, add the user accounts to this group for the users who are authorized to administer the iServer. Result: · iManager users in the Administrators or iServerAdmins group will have full permissions on the iServer. · iManager users who are in the iServerStaff user group 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 5. STEP 5: CONFIGURE AGENTS INTO Their 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 the iTivity User Guide, Section 5.3 Editing the Agent HTML Files and Section 5.5, Installing the Admin Agent or Live Support Agent From the Distribution EXE. Example: To continue the example discussed above: 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. Step 6: AUTHENTICATE INTO the SUPPORT DOMAINS
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.
Note: If the iManager user specifies no support domain in the authentication dialog, then that user is requesting global access. In order to obtain the global access, the iManager user must be a member of the global access group, either “iTivityServerUsers” (Windows) or “isrvauth” (UNIX). If the iManager user is a member of this group, he or she will have access to all Agents connected to the iServer and will have all permissions granted. Example: iManager users based in GA should enter “GA” into the Support Domain field of the Authentication dialog shown above. iManager users based in TX should enter “TX” into the Support Domain field of the Authentication dialog shown above. How Support Domains Are Authenticated
The 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. · If an iManager user is a member of the global access group, then he or she may specify a support domain to act as a filter at the iServer, without having explicit membership in the support domain security group.
Copyright © 2017 - 2023, iTivity Corporation |
