Users, groups, roles and path ACLs
Permissions in Proxmox combine three things: who (a user or group), which role (a set of privileges, e.g. PVEVMAdmin) and on what (a path: /, /vms/<id>, a resource pool, storage). You grant a permission as an ACL entry on a path — and it inherits down the tree.
Group resources into Pools (e.g. a "Dept-X" pool) and assign roles on the pool — rather than on individual VMs. Less clicking, fewer mistakes.
Sign in with a corporate account
Proxmox supports several authentication sources (realms): local PAM, built-in PVE and LDAP/Active Directory. You add an AD realm under Datacenter → Permissions → Realms, providing the server, the domain and a bind account to query the directory. The LDAP search base is a separate field, not the domain name. A Proxmox account must still exist — added by hand or by sync — before that person can log in.
- User/group sync: Proxmox can periodically sync objects from AD (Sync Options), so a new employee in the right AD group gets access automatically.
- Connection security: use LDAPS (TLS), a least-privilege bind account and filters that limit the sync scope.
Access via groups, not accounts
The key to maintainable access: assign roles to groups, not individual people. Example: AD group Proxmox-Admins is stored after sync as Proxmox-Admins-ad (group name, hyphen and realm name — in this example the realm is called ad; for a realm named corp it would be Proxmox-Admins-corp) → role Administrator on /. An ACL on the bare AD name does not apply. After sync, Dept-X-Operators is stored as Dept-X-Operators-ad → role PVEVMAdmin on the Dept-X pool. Granting/revoking access then comes down to changing AD membership — in one familiar place. Proxmox group names may contain only ASCII letters, digits, dots, hyphens and underscores — AD groups whose names contain any other character are skipped during sync. A pool name uses the same set, and a slash separates nesting (at most three levels).
Built-in roles (PVEVMAdmin, PVEDatastoreUser, PVEAuditor…) cover most cases. When needed, you create a custom role with exactly the privileges you choose.
Governance, audit and lower risk
- Least privilege: everyone has exactly the access they need — a smaller attack and error surface.
- Single source of truth: when an employee leaves, disabling their AD account blocks the next password login to Proxmox. It does not revoke an existing session or API tokens — revoke the tokens or disable the Proxmox user as well.
- Auditability: clear roles and groups make demonstrating compliance easier (ISO 27001, NIS2, internal policies).
- API tokens: automation and integrations get their own scoped tokens instead of human passwords.
We'll implement a secure access model
We'll design roles, pools and Active Directory integration following least-privilege and your compliance requirements.
⚡ Free consultation→ 2FA in Proxmox