Requirements and considerations | RS

A Gateway-facilitated BeyondTrust session involves three computers:

• The BeyondTrust user's system
• A computer that hosts the Gateway
• The unattended computer targeted for remote control

There are various permission, hardware, software, and port requirements for these systems that must be met or should be considered when installing a Gateway.

Review Gateway permission requirements

The administrator deploying the Gateway must have administrative rights on the computer hosting the Gateway.

Users must have the following permissions to access the Gateway:

• The user must have administrative rights to the target computer.
• In the administrative interface, one or both of the following conditions must be true:
  • The user must have the account permission Allowed Connection Types: Local Jump.
  • The user must have the account permission Allowed Connection Types: Remote Jump and must be granted access to one or more Gateways, either individually or via a group policy.

ℹ️

For more information, see the following:

• On user permissions, Remote Support Users and Security.
• On Group Policies, Remote Support Group Policies.

Review Gateway installation considerations

The main objective of any BeyondTrust administrator should be to ensure the integrity of the BeyondTrust deployment. The simpler and more straightforward a BeyondTrust deployment is, the easier it is to maintain a level of integrity that is in line with your company's security objectives. Specifically, when deploying a Gateway on a remote network, another layer of complexity is introduced to your deployment. Therefore, BeyondTrust recommends using a dedicated resource for a Gateway in order to decrease any potential security risks, increase availability, and reduce management complexity. A dedicated resource is most often a virtual machine or sometimes a physical machine with the sole purpose of hosting the Gateway.

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 Gateway host. When using a shared resource, the BeyondTrust administrator must be aware of everything for which the shared resource is used. For example, the BeyondTrust 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 Gateway host. BeyondTrust encourages adding your own list of pros and cons before deploying a Gateway on a shared resource.

Security questions

• Who has access to this resource?
• Are file shares accessible on this resource?
• Are there group policies in place that may restrict Gateway functionality?
• What is the risk of virus infection or malware due to multi-user access?
• What is the risk of another user changing the system permissions or deleting needed files?

File/print sharing questions

• 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 Gateway performance.

Other shared resource questions

• How critical is availability? What is the risk of the Gateway not being available?
• How frequently will this Gateway be used?
• What is the potential number of Sessions that will need to be run through this Gateway at the same time?
• Will shared responsibility of this resource across different departments increase complexity?

ℹ️

A Gateway cannot be used to access itself, because that is an unsupported loopback connection.

Review Gateway hardware and software requirements

Host hardware and software requirements – all session types

An average server class machine for a supported operating system, with 16GB of RAM, can readily support 25 concurrent sessions of any type (100 serial-over-LAN sessions, 200 Telnet or SSH sessions). Additional sessions are supported depending on the session types and other factors, or with higher server specifications.

ℹ️

For more information about hardware and software requirements, see Remote Support supported platforms.

Session-specific host and target software requirements

Except as noted, the target and the host must be on the same network.

Remote Sessions – host system requirements

A domain account that has local admin rights on the target computer(s).

The following applies to Windows systems:

• By default, the Gateway runs under the local system account. This should be changed to an account that has local admin rights on the target computer(s).
• Follow these steps if this account is changed:
  • Log on to the Gateway host system as an administrator.
  • Stop the BeyondTrust Gateway service using services.msc.
  • Navigate to C:\ProgramData\BeyondTrust\Gateway\hostname or C:\Users\All Users\Application Data\BeyondTrust\Gateway\hostname, depending on the Windows version.
  • Open the properties for settings.ini and go to the Security tab. Click Continue to view the security properties.
  • Select the Users or Everyone group, depending on the Windows version.
  • Uncheck the Read permission in the Deny column.
  • Apply the changes.
  • The Gateway may now be safely changed to be under a different account.
  • Restart the Gateway 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).

Remote/Local Sessions – target system requirements

The following applies to Windows systems:

• The Workstation service must be running (check using services.msc).
• The Server service must be running (check using services.msc).
• The Remote Registry service must be running (check using services.msc).
• The ADMIN$ share must be available (check using Computer Management).
• The Windows Network must be running, and printer and file sharing must be activated.
• Make sure firewall settings do not block the connection. If the firewall blocks incoming traffic, open port 445 (and possibly 135) on the target computer for incoming traffic.

Shell Sessions – host system requirements

No session-specific host system requirements.

Shell Sessions – target system requirements

Any available SSH server.

vPro sessions – host system requirements

No session-specific host system requirements.

vPro sessions – target system requirements

Any pre-provisioned vPro system, running AMT version.

Remote RDP sessions – host system requirements

No session-specific host system requirements.

Remote/Local RDP sessions – target system requirements

Microsoft Remote Desktop Protocol (RDP) must be enabled on the target system.

ℹ️

Remote Support supports only Microsoft's RDP server implementation built into Windows operating systems and Remote Desktop Session (formerly Terminal Services) Hosts.

Remote VNC sessions – host system requirements

No session-specific host system requirements.

Remote/Local VNC sessions – target system requirements

Listening VNC server supporting RFB protocol 3.8 or earlier, configured for basic or no authentication.

Review port requirements for discovery and rotation of Vault accounts

Active Directory:

• Port 389
• Port 636

Local account management:

• Port 445