VMware ESXi and vSphere Cluster Management

VMware vSphere and ESXi Access Control System

Learn how vCenter Server and ESXi use privileges, roles, users, groups, permissions, inheritance, and Active Directory to control administrative access.

VMware vSphere access control determines who can manage virtualization resources and which operations each person or service may perform. The model combines identities, roles, privileges, permissions, and inventory scope.

This lesson focuses on both vCenter Server authorization for centrally managed inventory and direct ESXi host access. For background, review VMware ESXi and the VMware ESXi online course.

Authentication, authorization, and access control

Authentication verifies an identity, such as a user account, service account, or directory group member. Authorization determines what that authenticated identity is allowed to do. Access control is the broader security process that restricts access to resources and management actions.

In a vSphere environment, vCenter Server centrally manages authorization for connected ESXi hosts and the inventory objects managed through vCenter. The practical goal is delegated administration: operators should be able to complete their jobs without receiving unrestricted Administrator access.

Core RBAC components

Role-based access control (RBAC) grants access through roles that contain privileges. A vSphere permission combines three things: an identity, a role, and an inventory object.

Privilege — An individual allowed action, such as powering on a virtual machine.

Role — A named, reusable collection of privileges.

Inventory object — A resource or container to which access can be assigned, such as a vCenter Server, datacenter, folder, cluster, host, resource pool, virtual machine, datastore, network, or distributed switch.

User — An individual identity that can authenticate and receive permissions.

Group — A collection of users that receives permissions as a unit.

Permission — The assignment of a user or group, a role, and an inventory object, optionally with propagation to child objects.

For example, the permission “AD\VM-Operators + VM Operator role + Test VMs folder” grants that group the privileges in the VM Operator role on the selected folder and, if propagation is enabled, its child virtual machines.

Privileges: individual capabilities

Privileges are granular capabilities organized into functional categories. Representative operations include powering a VM on or off, editing VM settings, configuring networks, creating alarms, accessing datastores, and managing host settings.

A user must have every privilege required by an operation at an applicable inventory scope. A role that permits VM power operations may still fail when a task also requires a configuration, datastore, or network privilege. Granting only the required privileges reduces the effect of account compromise and limits accidental changes.

Privilege names and required combinations can vary by operation and vSphere release. Identify the exact failed task, inspect the relevant privilege category, and test the role with a non-administrative account rather than assuming that a similarly named permission is sufficient.

Roles: reusable privilege sets

Roles package privileges into reusable permission sets. A role assignment by itself does not grant access; the role must be used in a permission on an inventory object.

Built-in roles

Administrator: broad management access. Reserve it for tightly controlled full-management accounts.
Read-Only: visibility without configuration changes. It is appropriate for auditors, monitoring users, and inspection-only access.
Custom roles: purpose-built collections of privileges for delegated duties.

Role design principles

Apply least privilege: include only the capabilities required for the job.
Group privileges by job function rather than by individual employee.
Use descriptive names such as VM-Operator-Test-Workloads or Network-Admin-Delegated.
Document the purpose, owner, included privileges, intended scope, and review date.
Separate duties so one role does not automatically combine unrelated administrative powers.
Review custom roles periodically and remove privileges that are no longer needed.

Do not create a custom role by copying excessive Administrator privileges and leaving them unreviewed. Start with the task requirements and add only what testing demonstrates is necessary.

Permissions and assignments

To create a permission in the vSphere Client, select the target inventory object, open its permissions view, add a permission, choose an identity, select a role, and decide whether the assignment propagates to child objects.

Select the narrowest inventory object that contains the required resources.
Open the object's Permissions view.
Add a permission and select a user or, preferably, a directory group.
Select an existing role or a documented custom role.
Choose propagation only when child objects should receive the access.
Save the assignment and verify the result with a representative non-administrative account.

Group-based assignment is generally easier to maintain. Onboarding and offboarding can be handled through directory membership without repeatedly editing vCenter permissions. Direct user assignments may be appropriate for exceptional, temporary, or tightly controlled cases, but they increase review overhead and can leave stale access behind.

Inventory hierarchy, scope, and propagation

The object selected for a permission determines where access begins. A permission can be assigned at the vCenter root, datacenter, folder, cluster, host, resource pool, virtual machine, datastore, network, or distributed switch level.

vCenter Server root — Can affect many datacenters and inventory branches when propagated. Use only for genuinely broad duties; the risk of unintended access is high.

Datacenter — Can cover folders, clusters, hosts, VMs, datastores, and networks within that datacenter. Suitable for datacenter-wide audit access, but broad for operators.

Folder — Can cover its child objects, commonly a controlled set of VMs. A good scope for workload teams.

Cluster — Can cover hosts, resource pools, and VMs associated with the cluster, depending on the operation and propagation behavior.

Host — Targets a specific ESXi host and its host-level management resources.

Virtual machine — Targets one VM. This is precise but may require many assignments.

Datastore — Targets storage access and datastore operations.

Network or distributed switch — Targets network configuration and distributed switching resources.

Inheritance is the application of a permission assigned to a parent object to child objects. Propagation is the setting that controls whether the assignment applies to those children. Broad assignments at higher levels can unintentionally expose many resources, so select the narrowest scope that meets the operational requirement.

Inheritance should be used for consistent access to a deliberately organized set of resources, such as a dedicated VM folder. Avoid it when child objects have different owners or sensitivity levels. Reorganizing inventory into purpose-specific folders often makes safe scope design easier.

Effective permissions and access evaluation

An identity's effective permission is the access remaining after vCenter evaluates direct permissions, inherited permissions, group membership, propagation, and the privileges required by the requested operation.

Direct and inherited assignments can coexist. A user may receive one role through a group at a datacenter and another directly on a VM. The resulting access must be reviewed as a whole rather than inferred from one role assignment. Administrators should verify from the perspective of the actual user or group.

Why an expected action fails

The role lacks a required privilege.
The permission is assigned to the wrong object or inventory branch.
Propagation is disabled, or inheritance does not reach the target object.
The user is not a member of the expected directory group.
The task is being performed directly on ESXi rather than through vCenter, so a different authorization model applies.

Delegated administration examples

Administrator — Full management for a small number of protected accounts. Exclude ordinary operations staff and use strong controls.

Read-Only auditor — Inventory and configuration inspection at an appropriate datacenter or vCenter scope. Excludes changes.

VM Operator — View assigned VMs and perform approved power operations in a dedicated VM folder. Excludes host, cluster, network, datastore, and unrelated VM administration.

Help Desk — Limited visibility and approved basic actions, such as viewing VM state or restarting selected test workloads. Excludes configuration and infrastructure changes.

Backup Administrator — Minimum privileges required by the backup product and workflow, assigned to protected VM folders or another documented scope. Excludes unrestricted administration.

Network Administrator — Required network configuration privileges on relevant network or distributed switch objects. Excludes broad VM and host administration.

Storage Administrator — Required datastore and storage-management privileges on selected datastores. Excludes unrelated network and VM configuration privileges.

Practical scope example

A support team needs to restart a limited set of test VMs. Create a constrained role and assign it to the support group on the Test VMs folder, with propagation to its VMs. Do not assign the role at the vCenter root or datacenter level. The scope is as important as the privileges in the role.

Identity sources, users, groups, and Active Directory

Centralized directory authentication gives organizations a consistent place to manage accounts, groups, lifecycle events, and security policies. vCenter can use directory-backed users and groups as identities in inventory permissions. Directory groups are usually preferable because responsibilities can change without changing every object permission.

Manage group membership in the identity provider. Review membership during onboarding, role changes, offboarding, temporary-access expiry, and scheduled access audits. Remove stale accounts and unused group memberships promptly.

ESXi Active Directory integration

Direct ESXi host access is separate from vCenter-managed inventory authorization. An account may be authorized through vCenter but lack direct host access, or be authorized on a host without broad vCenter permissions.

Before joining an ESXi host to Active Directory, verify:

Forward and reverse DNS resolution as required by the environment.
Accurate time synchronization between the host and directory infrastructure.
Network reachability to domain controllers and required directory services.
Sufficient directory credentials and permission to join the host.
An approved directory group for host-level access.

Configure and test DNS and time synchronization.
Confirm routing and firewall connectivity to domain services.
Join the ESXi host to the domain through its host authentication or directory-service settings.
Authorize the approved domain user or group for host-level administration.
Test sign-in and retain a secure, documented local recovery account.

Local ESXi accounts remain distinct from directory identities. Protect local emergency access, avoid shared credentials, and document when recovery access is used. For related host administration, see basic ESXi configuration and communication between vCenter Server and ESXi.

Management scope — vCenter access controls managed inventory across connected hosts; direct ESXi access controls one host and its local management surface.

Identity source — vCenter commonly uses configured identity sources and directory users or groups; ESXi can use local accounts and, after integration, directory identities.

Permission target — vCenter permissions target inventory objects; direct ESXi authorization targets the host.

Typical use — vCenter is used for centralized VM, cluster, datastore, and network administration; direct host access is used for host-level administration, recovery, and carefully controlled troubleshooting.

Administrative consideration — Do not assume that authorization in one path automatically grants authorization in the other.

Secure administration practices

Apply least privilege to every role and permission.
Use separate named administrative accounts instead of shared credentials.
Limit Administrator-level accounts and protect them with stronger controls.
Use directory groups, documented role owners, approval workflows, and regular access audits.
Remove unused permissions, stale accounts, and expired temporary access.
Plan break-glass access for emergencies, protect its credentials, monitor its use, and test the recovery procedure.
Coordinate permissions with logging, auditing, directory security, and multifactor authentication where supported.
Test changes with non-administrative accounts before declaring a delegation complete.

Managing permissions in the vSphere Client

Reviewing an object

Browse to the inventory object whose access you want to inspect.
Open its permissions view and identify direct and inherited assignments.
Record the identity, role, propagation state, and source object for each relevant assignment.
Inspect parent objects when inherited access may be involved.

Creating or editing a role

Open the roles administration area.
Create a custom role or select an existing role for review.
Select only the privileges required for the documented operational task.
Save the role with a descriptive name, purpose, owner, and review date.

Adding, changing, and removing access

Select the intended object and open Permissions.
Add a permission, select the directory group or exceptional user, and choose the role.
Enable propagation only when child objects should inherit the assignment.
Review the resulting object coverage and effective access.
Modify or remove obsolete assignments, then test the intended actions and boundaries.

Client labels can differ slightly by vSphere release. The security logic remains the same: identity plus role plus object, evaluated with scope and propagation. For a focused procedure, see assign permissions.

Troubleshooting access problems

User can sign in but cannot perform a VM action

Identify the exact failed action and required privilege category.
Review the role's included privileges.
Confirm the assignment is on the correct object and propagates to the VM.
Check the user's current directory group membership.
Review direct and inherited permissions on the target VM and its parents.

Group can manage too many VMs

Inspect whether the assignment was made at the vCenter root, datacenter, or another broad parent.
Check whether propagation exposes unintended child objects.
Move the assignment to a dedicated folder or narrower object.
Review group membership and separate users with different responsibilities.

Domain user cannot authenticate to ESXi

Validate DNS resolution, NTP, routing, and firewall connectivity.
Confirm that the host successfully joined the domain.
Verify the exact domain identity and group membership.
Review host authentication and host-level authorization settings.

User has vCenter access but not direct ESXi access

Determine whether the task is being performed through vCenter or directly on the host.
Review ESXi directory integration and host-level authorization.
Use the identity and permission model appropriate to the selected management path.

Exam-relevant summary

Authentication verifies identity; authorization determines permitted actions.
A privilege is one capability; a role is a collection of privileges.
A permission combines an identity, a role, and an inventory object.
Role assignment alone grants nothing until it is used in a permission.
Propagation controls whether access reaches child inventory objects.
Effective access includes direct permissions, inherited permissions, group membership, scope, and required privileges.
Use the narrowest practical scope and prefer directory groups for maintainability.
vCenter inventory permissions and direct ESXi host access are separate authorization paths.