Windows Client Should Install and Run as a System Service (No Admin Required for Users)

[karol-exe]

Summary

The current Windows client requires local administrator privileges to start and establish a Pangolin connection. Please add a service-based architecture where Pangolin installs a Windows system service (installed once with admin rights), allowing standard users to authenticate and connect without elevation.

Motivation

In many real-world Windows environments (enterprise, Intune/MDM-managed endpoints, least-privilege setups), end users do not have—and should not have—local administrator privileges. Requiring elevation to run the client makes Pangolin effectively unusable for standard users and prevents broader adoption in corporate deployments.
A Windows tunnel/agent typically runs privileged networking operations in a background service, while a user-facing UI runs unprivileged and communicates with the service. Implementing this pattern would enable secure, scalable deployments and align with Windows best practices for enterprise software.

Proposed Solution

Introduce a Windows Service mode for the Pangolin client.

1. Installer behavior (one-time admin)

Installation requires admin rights only once.
Installer registers a Windows service (e.g., PangolinAgent) configured to run as:

LocalSystem (default), or optionally
a dedicated service account (advanced scenario).

Service can be set to:

Automatic (Delayed Start) by default, and/or
Manual with a user-triggered start.

2. Service responsibilities (privileged background)

Owns all operations that currently require elevation:

network/tunnel setup
privileged system changes (routes, adapters, firewall rules if applicable)
persistent reconnection logic

Writes logs to a machine-wide location (e.g., C:\ProgramData\Pangolin\logs).
Exposes a local IPC interface (secure by default):

Named pipe (recommended) or local loopback API
Access restricted to:

local Users for status/read-only, and
a configurable local group (e.g., Pangolin Operators) for connect/disconnect actions.

3. User-level UI/CLI (no admin)

A per-user UI or CLI can:

authenticate (interactive login)
request “connect / disconnect”
show status and logs

The UI does not perform privileged networking operations directly; it only sends commands to the service.

4. Credential handling (recommended approach)

User tokens should be stored per-user (DPAPI user scope) or
passed to the service for session establishment without persisting secrets system-wide.
Optionally support SSO flows (future enhancement), but not required for initial implementation.

5. Packaging & deployment

Provide an MSI/EXE installer suitable for Intune/SCCM/GPO deployment.
Silent install options:

/quiet or equivalent
optional config parameters (endpoint, attach ID, etc.)

Ensure upgrades preserve service configuration and reconnect behavior.

Expected user experience

Admin installs Pangolin once.
Any standard user logs in and clicks “Connect” without elevation prompts.
Tunnel remains stable across user logoff/logon (if desired), or can be user-session scoped (configurable).

Alternatives Considered

Run-as-admin instructions / UAC prompts

Not viable in least-privilege environments; users cannot elevate.

Scheduled Task running as SYSTEM

Possible workaround, but not as clean as a proper Windows service:

harder lifecycle management
poorer logging/updates
can be brittle across upgrades

Bundling helper binaries (e.g., elevating only a small portion)

Still requires elevation at runtime and complicates security review.

Additional Context

This feature is critical for enterprise/managed environments where local admin rights are intentionally restricted.
Many comparable tunnel/VPN clients on Windows use a service + UI split to keep privileged operations in a controlled, auditable component.
I can provide testing feedback on:

Windows 10/11 standard user scenarios
Intune deployment packaging
service/IPC security expectations (least privilege, restricted access, logging).

[dohlin]

Man...super bummed and honestly confused on how this isn't already a feature. Trying to sell Pangolin to my boss for our org but this is going to be a non-starter unless I'm missing something obvious on how to install the Windows client as a service.

EDIT: Nevermind...I think...it looks like after running the .msi and providing admin creds, admin creds just need to be provided one more time when launching the Pangolin client for the service running as LOCAL SYSTEM to get installed