Vendor Access Overview
What is Vendor Access?
Vendor Access is a feature of Admin By Request's Secure Remote Access product that allows external users, such as third-party vendors, to be given secure access to internal devices. This access is managed entirely through their local Internet browser app - there is no need for any additional locally installed software.
Related information
Prerequisites
The main prerequisite for Vendor Access applies to Single Sign-On, where SSO must be enabled for each user who will login to the Vendor Access page (https://access.work).
Additional requirements depend on whether or not you are using Cloudflare's managed service as a gateway, or hosting your own on-premise gateway. These requirements are covered below and are the same as those outlined in the Unattended Access and Remote Support IT Admin Guides.
Prerequisites are listed under these headings:
-
Data location
-
Cloud gateway (managed service)
-
On-premise gateway (self-hosted)
Data location
Your data is stored in a data center that is located in one of two geographic locations - one in Europe and one in the USA.
To determine your data center, go to page Tenant Settings > API Keys in the portal and check which API prefix is shown under About API Keys. The API prefix will be one of the following:
-
https://dc1api.adminbyrequest.com (Europe)
-
https://dc2api.adminbyrequest.com (USA)
Make a note of your prefix - among other things, this is the domain used when an API Key is created.
You can also see your API prefix on the API web pages (e.g. Public API > Auditlog API). However, a small script runs in the background that determines to which data center you are attached, so JavaScript must be enabled in your browser for this to work.
Cloud gateway (managed service)
-
Access to the portal at https://www.adminbyrequest.com/Login
-
Admin By Request for Windows 8.4.0+ on each client
-
Admin By Request API - port 443 for the following:
-
api1.adminbyrequest.com (if your data is located in Europe)
-
api2.adminbyrequest.com (if your data is located in the USA)
-
api.adminbyrequest.com
-
-
Outbound MQTT broker connectivity via Websockets- port 443 for the following:
-
If your data is located in Europe:
ten nodes (FastTrackHubEU1.azure-devices.net to FastTrackHubEU10.azure-devices.net) -
If your data is located in the USA:
ten nodes (FastTrackHubUS1.azure-devices.net to FastTrackHubUS10.azure-devices.net)
-
-
Cloudflare connectivity:
-
UDP outbound - port 7844 for the following:
-
region1.v2.argotunnel.com
-
region2.v2.argotunnel.com
-
If your firewall supports Server Name Indication (SNI), you need to allow the following URLs (UDP outbound - port 7844):
-
cftunnel.com
-
h2.cftunnel.com
-
quic.cftunnel.com
-
-
The endpoint needs to be enrolled with an Admin By Request Secure Remote Access license (see Product Enrollment).
-
For Windows endpoints, RDP needs to be enabled on port 3389 on each device.
Refer to https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/deploy-tunnels/tunnel-with-firewall/ for more information on Cloudflare's "tunnel with firewall" configuration.
On-premise gateway (self-hosted)
-
Access to pull Docker images from adminbyrequest.azurecr.io
-
Admin By Request API - port 443 for the following:
-
connectorapi1.adminbyrequest.com (if your data is located in Europe)
-
connectorapi2.adminbyrequest.com (if your data is located in the USA)
-
-
Outbound MQTT broker connectivity via Websockets- port 443 for the following:
-
If your data is located in Europe:
ten nodes (FastTrackHubEU1.azure-devices.net to FastTrackHubEU10.azure-devices.net) -
If your data is located in the USA:
ten nodes (FastTrackHubUS1.azure-devices.net to FastTrackHubUS10.azure-devices.net)
-
-
Cloudflare connectivity:
-
UDP outbound - port 7844 for the following:
-
region1.v2.argotunnel.com
-
region2.v2.argotunnel.com
-
If your firewall supports Server Name Indication (SNI), you need to allow the following URLs (UDP outbound - port 7844):
-
cftunnel.com
-
h2.cftunnel.com
-
quic.cftunnel.com
-
- In order for the on-premise gateway to be able to discover devices on the network, these need to be available to the gateway on ports 3389 (RDP), 22 (SSH) or 5900/5901 (VNC).
Refer to https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/deploy-tunnels/tunnel-with-firewall/ for more information on Cloudflare's "tunnel with firewall" configuration.
How does Vendor Access work?
Architecture
The idea behind Vendor Access is to allow users to connect to your remote endpoints using nothing but their browsers.
In order to achieve this, the browser creates a Secure WebSocket connection to a Docker-based gateway, hosted either in your own infrastructure (self-hosted) or as a managed service.
The gateway comprises three different images:
-
Connector
Handles validation and translation of the data between the portal and the proxy container, as well as managing logs, health checks and other data. -
Proxy
Establishes a protocol connection between Admin By Request and your endpoint using either RDP, SSH or VNC. -
Discovery
Handles automatic discovery of connectable devices running on the same network as the gateway.
Process
The process by which a user establishes a Vendor Access session is:
-
The user initiates a connection from https://access.work.
-
The Admin By Request client on the target endpoint receives an instruction from the MQTT Broker to fetch settings using the Admin By Request API.
-
The settings response instructs the Admin By Request client to open a Cloudflare Tunnel by making an outbound UDP call on port 7844 using the QUIC Protocol.
-
The Gateway is instructed to forward the RDP, SSH or VNC connection through the tunnel opened by the endpoint.
-
A secure WebSocket connection is established between the user's browser and the Gateway. The response stream from the RDP, SSH or VNC connection is routed back to the browser using this secure connection.
The process is illustrated in the following diagram:
What next?
This