Proxmox permissions and Active Directory integration

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.

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, domain (base DN) and a bind account to query the directory. From then on employees log in with their domain credentials — without creating separate Proxmox accounts.

• 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 → role Administrator on /; group Dept-X-Operators → role PVEVMAdmin on the Dept-X pool. Granting/revoking access then comes down to changing AD membership — in one familiar place.

Governance, audit and lower risk

• Least privilege: everyone has exactly the access they need — a smaller attack and error surface.
• Single source of truth: an employee leaving = disabling their AD account revokes access everywhere, Proxmox included.
• 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.