Remote Access (Guacamole + Authelia)

Summary

Secure, browser-based remote access, standardized the same way for every customer — no separate app to install, no separate URL for "extra secure" access versus regular access, and no fragile IP-allowlist to maintain by hand.

  • One URL, handles both cases automatically — staff working from the office get straight in with just their AD password; staff working remotely get a second factor required automatically, based on where they’re actually connecting from.

  • No email dependency for two-factor setup — enrollment is a QR code shown directly on screen, scanned once, done. Nothing to wait on, nothing that can get stuck in a spam filter.

  • Standardized, not bespoke per customer — the same architecture deploys for every customer, cloned and adapted in a couple of hours rather than built from scratch each time.

  • Real, current investment in stronger authentication — some customer environments are actively piloting an additional device-certificate layer on top of the standard setup (more below).

This is also the concrete expression of a broader stance: moving customer workloads into the private cloud, with this as the standard way staff reach them — not a bolt-on remote-access tool, the actual front door.

How It Works

Internet
    v  HTTPS
nginx reverse proxy
    v  AD/LDAP authentication (first factor)
Authelia
    v  authenticated username, passed through securely
Guacamole
    v  TOTP required only for external connections
Remote desktop session

Two systems each do one job: Authelia handles the AD password check, Guacamole decides whether a second factor is required at all — based on where the connection is actually coming from. Internal, on-site connections skip the second factor entirely; anything external gets it automatically. Nobody has to remember which URL to use for which case, because there’s only one.

Why This Design, Specifically

No IP Allowlisting

A tempting-sounding shortcut — restrict access to a known list of IP addresses — doesn’t hold up in practice. Residential and mobile IPs change constantly, turning an allowlist into a recurring support burden instead of a real security control. AD credentials plus a genuine second factor is a stronger security posture on its own, without that operational cost.

Two-Factor Without the Email Bottleneck

Enrollment happens once, directly on screen — a QR code, scanned with any standard authenticator app. No email round-trip, no waiting on a code that might land in spam, no support ticket because someone’s enrollment email never arrived.

Standardized, So It’s Actually Maintainable

The same two-VM architecture (a proxy layer and a remote-access layer) deploys for every customer, with per-customer secrets and credentials that are never reused across customers. Standardizing the pattern is what makes it realistic to actually keep every customer’s deployment current and consistent, rather than accumulating one-off configurations that each need their own tribal knowledge to maintain.

In Progress: Device-Certificate Hardening

Select customer environments are currently piloting an additional authentication layer — a device-bound client certificate, required before the standard AD-and-TOTP flow even begins. Where deployed, this means a device has to be specifically authorized before it can even attempt to log in at all, on top of the existing password and one-time-code requirements. This is real, active work, not a universal feature yet — broader rollout depends on how the pilot goes.

Get in touch to talk through what this looks like for your environment.