Requirements and Considerations to Install a Jumpoint
A Jumpoint-facilitated Bomgar session involves three computers:
- The support representative's system
- A Windows computer that hosts the Jumpoint
- The unattended Windows computer targeted for remote control
- The administrator deploying the Jumpoint must have administrative rights on the computer hosting the Jumpoint.
- The support representative must have administrative rights to the target computer.
- In the Bomgar administrative interface, one or both of the following conditions must be true:
- The representative's account permission Allowed to Jump on the local network without a Jumpoint must be enabled.
- The representative must be granted access to one or more Jumpoints, either individually, via group policy, or via embassy group.
The main objective of any Bomgar administrator should be to ensure the integrity of the Bomgar deployment. The simpler and more clear-cut a Bomgar deployment is, the easier it is to maintain a level of integrity that is in line with your company's security objectives. When deploying a Jumpoint on a remote network, another layer of complexity is introduced to your deployment. Therefore, Bomgar recommends using a dedicated resource for a Jumpoint in order to decrease any potential security risks, increase availability, and reduce management complexity.
If a dedicated resource is not readily available, there are several factors to take into consideration before deciding to use a shared resource as a Jumpoint host. When using a shared resource, the Bomgar administrator must be aware of everything for which the shared resource is used. For example, the Bomgar administrator would need to identify and control any unwanted changes to or repurposing of the resource by other groups, especially in large organizations.
There are many other variables that are unique to any given network or business environment. The questions below are provided to encourage a proactive approach before pursuing the use of a shared resource as a Jumpoint host. Bomgar encourages adding your own list of pros and cons before deploying a Jumpoint on a shared resource.
- Who has access to this resource?
- Are file shares accessible on this resource?
- Are there group policies in place that may restrict Jumpoint functionality?
- What is the risk of virus infection or malware due to multi-user access?
- What is the risk of another user's changing the system permissions or deleting needed files?
- What other programs will be competing for resources such as disk space, processor availability, bandwidth, and disk access?
- Will the resource be available at all times? How critical is on-demand access?
- What is the risk of permission modification on file shares?
- Will this resource be used frequently for print jobs? Large or frequent print jobs can consume a large amount of resources, adversely affecting Jumpoint performance.
- How critical is availability? What is the risk of the Jumpoint not being available?
- How frequently will this Jumpoint be used?
- What is the potential number of Jump sessions that will need to be run through this Jumpoint at the same time?
- Will shared responsibility of this resource across different departments increase complexity?
Host System Requirements
- Windows XP - Windows 8 or Windows Server 2000 - Windows Server 2012 (excluding Windows XP Home).
- The host system can be but is not required to be a member of the domain.
- By default, the Jumpoint runs under the local system account. In certain environments, this may need to be changed to a domain account that has local admin rights on the target computer(s). This is applicable only if the host system is a member of the domain.
- If this account is changed, then the following steps must first be taken:
- Log onto the Jumpoint host system as an administrator.
- Stop the Bomgar Jumpoint service using services.msc.
- Navigate to C:\ProgramData\Bomgar\Jumpoint\hostname or C:\Users\All Users\Application Data\Bomgar\Jumpoint\hostname (depends on Windows version).
- Open the properties for bomgar.ini and go to the Security tab. Click Continue to view the security properties.
- Select the Users or Everyone group (depends on Windows version).
- Uncheck the Read permission in the Deny column.
- Apply the changes.
- The Jumpoint may now be safely changed to be under a different account.
- Restart the Jumpoint service using services.msc.
- File sharing must be turned on, specifically IPC$ and ADMIN$.
- The Remote Registry service must be running (check using services.msc).
Hint: You may find it helpful to review how to enable a Windows Service.
Target System Requirements
On the target computer, make sure that:
- It is running Windows XP - Windows 8 or Windows Server 2000 - Windows Server 2012 (excluding Windows XP Home).
- The Remote Registry service is running (check using services.msc). Optional when using Bomgar 12.3 or higher.
- The Server service is running (check using services.msc).
- The Workstation service is running (check using services.msc).
- The ADMIN$ share is available (check using Computer Management).
- The Windows Network is running and printer and file sharing are activated (no need to actually share anything).
- Incoming network users authenticate as themselves. To achieve this, follow the steps below:
- Turn off simple file sharing, and enable classical file sharing.
- Turn off network users identified as guests, and enable network users to identify themselves.
Example: Open secpol.msc > Local Policies > Security Options. Make sure that Network access: Sharing and security model for local accounts is set to Classic – local users authenticate as themselves.
Note: Classic Network Authentication requires a non-empty password.
- Make sure firewall settings do not block the connection. By default on Windows XP SP2, the firewall will block any incoming traffic. It may therefore be necessary to open port 445 (and possibly 135) on the target computer for incoming traffic.