Connecting to your Azure VMs with TYO Reach
Give your team — including external contractors — one-click RDP/SSH access to VMs in your Azure subscription, through Azure Bastion's native-client tunnelling. No VPN, no public IPs, no separate jump box to run.
Throughout this document, "Reach" refers to TYO Reach.
1. How it works (30-second version)
User's laptop ──(Reach client)──► Microsoft Entra ID ──► Azure Bastion ──► your VM
- The user clicks a machine in the Reach tray and signs in with their Microsoft work or school account.
- Microsoft Entra ID checks they're allowed (RBAC), enforces your Conditional Access / MFA policies, and Reach opens a tunnel through your Azure Bastion.
- Reach binds a local port and launches RDP or SSH to it.
Microsoft and your Azure RBAC enforce all access and identity. Reach provides the one-click client and the audit trail. Traffic goes directly from the user through Azure Bastion to your VM — it never passes through Reach's servers (so it's also outside any Reach data allowance, and there's no third party in your data path).
Azure Bastion itself is billed by Microsoft (it needs the Standard SKU, with native-client support enabled) — Reach doesn't add a per-use fee on top.
2. What your Azure admin sets up (one-time, per VNet)
2.1 Deploy Azure Bastion with native client support
You need an Azure Bastion instance, Standard SKU, deployed in the target VM's virtual network, with native client support (tunnelling) enabled. The Basic SKU doesn't support this — Standard is required.
2.2 Grant the user RBAC access
The signing-in user needs role-based access to reach the VM through Bastion:
- Reader on the Bastion resource.
- Reader (or equivalent) on the target VM.
- Network-level access to the VM's virtual network/NIC, per your organisation's RBAC model.
Scope these roles to the specific VM or resource group for least privilege, the same way you would for a contractor.
2.3 One-time tenant consent for the Reach app
Reach's Azure integration is a multi-tenant Entra app ("Reach"). The first time anyone in your tenant signs in through it, an admin (or the signing-in user, depending on your tenant's consent policy) approves the app's requested permissions — a one-time step per tenant, not per user or per VM.
2.4 Give the user a way to log into the OS
Azure RBAC and Bastion control the tunnel; the VM still checks the login — a Windows username/password (RDP) or SSH key/credentials (SSH). These are separate from the RBAC grant above.
3. What gets configured in Reach (per VM)
An admin adds a Remote target in the Reach dashboard's Targets tab:
| Field | Value |
|---|---|
| Backend | azure-bastion |
| Subscription | your Azure subscription id |
| Resource group | the resource group containing the Bastion (and usually the VM) |
| Bastion | the Bastion resource's name — not its resource ID |
| Target resource ID | the VM's full Azure resource ID, e.g./subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachines/<vm> |
| Port | 3389 (RDP) or 22 (SSH) |
| Protocol | rdp / ssh |
You don't set a tenant ID here — Reach resolves it from the signed-in user's Microsoft account at connect time.
Enabled targets sync to every member of your organisation with the desktop client automatically.
4. What the end user does
- Install the Reach desktop client (Windows / macOS / Linux).
- Sign into Reach.
- Open the tray → Remote targets → click the VM.
- First time only: a browser opens to sign in with your Microsoft work or school account — use the identity that was granted RBAC access (2.2). Approve the one-time tenant consent (2.3) if you're the first person in your organisation to connect.
- Reach opens the tunnel through Azure Bastion and launches RDP/SSH automatically. Subsequent connects are one click (the Microsoft sign-in is cached until it expires).
No VPN client, no jump box credentials, nothing for the end user to configure.
5. Security & governance
- Access is Azure RBAC's to grant and revoke. Remove the role assignment (2.2) and the person loses access immediately — nothing lingers on their machine.
- Least privilege: scope Reader/network roles to the specific VM or resource group rather than the whole subscription.
- MFA / Conditional Access: enforced by your Entra tenant policies (Security Defaults or Conditional Access). Reach rides on top — it can't bypass them.
- Audit: Bastion sessions appear in your Azure Activity Log / Bastion diagnostic logs; Reach can additionally record a per-connection audit trail on the Reach side.
- Data path: user ↔ Entra ID ↔ Azure Bastion ↔ VM. Reach is never in the traffic path.
6. Troubleshooting
| Symptom | Cause / fix |
|---|---|
| "AADSTS530035" or a device-code sign-in error | Expected — device-code is blocked under Security Defaults. Reach uses authorization-code + PKCE instead; make sure you're on the current Reach client version. |
| Microsoft sign-in succeeds, then no connection | The account is missing RBAC on the Bastion or VM (2.2), or hasn't completed the one-time tenant consent (2.3). |
| "Connection refused" / times out at the VM | Bastion isn't Standard SKU, or native-client support isn't enabled (2.1). |
| RDP/SSH opens but the login is rejected | That's the OS credential (2.4), separate from RBAC/Bastion access. |
| Target doesn't appear in the tray | The user isn't signed into Reach, or your organisation isn't on a Team plan. |
| Wrong machine reached | Check Subscription / Resource group / Target resource ID in the Reach target config (section 3). |