VMware ESXi and vSphere Cluster Management

VMware vSphere Access Control System: Privileges, Roles, Users, Groups, and Permissions

Learn how vCenter Server and ESXi use privileges, roles, users, groups, and permissions to control access to vSphere inventory objects.

VMware vSphere access control determines who can perform which actions on which infrastructure resources. The system is built around role-based access control (RBAC): administrators combine individual privileges into roles, then assign those roles to users or groups on inventory objects.

This lesson covers centralized authorization through vCenter Server, host-local ESXi access, role and permission design, Active Directory integration, delegated administration, validation, and troubleshooting.

Purpose and scope of vSphere access control

Authentication establishes who an identity is. Authorization determines what that identity may do. vSphere access control primarily addresses authorization after a user or service has authenticated.

In a vCenter-managed environment, an access decision has three essential parts:

• Identity: the user or group requesting access.
• Target: the inventory object being accessed, such as a virtual machine, folder, cluster, datastore, network, host, or datacenter.
• Action: the operation allowed by the assigned privileges, such as powering on a virtual machine or changing a configuration.

RBAC limits access by assigning capabilities through named roles rather than granting every action separately to every user. This supports delegated administration: different teams can manage different portions of the inventory without receiving unrestricted control of the whole environment.

vCenter authorization versus ESXi host access

vCenter Server provides centralized authorization for objects managed through vCenter. Permissions can be assigned at levels such as the vCenter inventory root, datacenter, folder, cluster, host, resource pool, datastore, network, virtual machine, and vApp. Assignments can often be inherited by child objects.

ESXi also has host-local access management. A standalone host, or a host being accessed directly, uses its own local accounts, identity configuration, and host permissions. Joining an ESXi host to a directory can allow domain identities to authenticate to that host, but this does not automatically replace the need to design vCenter permissions. Always identify whether an administrator is connecting to vCenter or directly to an ESXi host.

Core authorization components

The following components work together:

The relationship can be summarized as follows:

Privileges -> bundled into a role
Role + user or group + inventory object -> permission
Permission + applicable inheritance -> effective access on an object

An effective permission is the access a user actually has on a particular object after applicable direct assignments, inherited assignments, role contents, and group memberships are considered.

Privileges

A privilege is authorization to perform a specific action on a vSphere inventory object. Privileges are organized into categories so administrators can select capabilities relevant to a job function.

Representative privilege areas include:

• Virtual machine operations: powering on, powering off, resetting, suspending, or opening a console.
• Virtual machine configuration: changing hardware, settings, or other configuration properties.
• Networking: managing virtual switches, port groups, or network-related configuration.
• Datastore access: browsing, allocating, or managing datastore resources.
• Alarm management: creating, modifying, or responding to alarms.
• Host administration: changing host configuration or performing host-management operations.

Use the least-privilege principle: grant only the capabilities required for the person's assigned work. A team that only needs to start and stop selected virtual machines should not receive host, datastore, or network administration privileges.

Broad privileges create both security and operational risk. An unnecessarily powerful account can alter production workloads, expose data, change network isolation, or interrupt services. Excess access also makes audits and incident investigations more difficult.

Roles

A role is a named, reusable collection of privileges. Roles translate technical capabilities into an access level or job function.

Built-in roles

Built-in roles provide starting points for common requirements:

• Administrator: broad control over the applicable vSphere scope. Limit this role to a small number of trusted administrators.
• Read-Only: permits viewing information without allowing normal configuration changes. It is useful for auditors, observers, and reporting users.

Built-in roles may not match every organization or operational boundary. Do not use Administrator merely because it is convenient when a narrower role is sufficient.

Custom roles

A custom role contains the privileges selected for a specific operational requirement. Useful designs include a VM operator, VM administrator, network administrator, datastore administrator, infrastructure administrator, or auditor role.

Document every custom role's purpose, owner, included privileges, approved use cases, and review date. A role is shared by every permission assignment that uses it. Changing the role can therefore change access for many users at once, including users in unrelated teams if the role was reused too broadly.

Permissions and assignment scope

To create a permission, select the target inventory object, select a user or group, and assign a role. In a vSphere management interface, the general workflow is:

1. Select the target inventory object.
2. Open the object's permissions management view.
3. Add the required user or group.
4. Select a built-in or custom role.
5. Choose whether the assignment should propagate to child objects.
6. Save the assignment.
7. Validate it with a representative, non-administrative account.

Inheritance and propagation

An inherited permission is assigned on a parent inventory object and applies to eligible child objects. Propagation is the application of that assignment from the selected object to its children.

For example, assigning a role to a group on a VM folder and propagating it to child objects can give the group access to the virtual machines in that folder. Assigning the same role at the vCenter root can affect a much larger portion of the environment.

Before changing access, inspect permissions on the target and its parent objects. Look for inherited assignments, direct user entries, group memberships, and other roles that may already grant access. Use propagation when all child objects should receive the same access. Prefer a narrower assignment when child objects have different owners, sensitivity, or operational requirements.

Users and groups

A user is an individual identity that can authenticate and receive permissions. A group is a collection of users managed as one access identity.

Direct user assignments can be appropriate for a temporary exception or a tightly controlled emergency case, but group-based access is normally preferable:

• Onboarding and offboarding can be handled through group membership.
• Auditors can review a stable assignment and then inspect membership separately.
• Access remains consistent across teams and environments.
• Individual permission sprawl is reduced.

Use approved directory groups for ordinary administrative access. Review both permissions and group membership periodically. Remove obsolete access promptly when a person changes duties or leaves the organization. Protect administrative accounts with strong authentication controls, restricted use, and appropriate monitoring.

Local and external identities

ESXi hosts have local accounts that can be used for host administration. These accounts are valuable for controlled emergency access, but they must be protected and reviewed. vSphere environments can also use configured external identity sources, allowing directory users and groups to receive permissions after identity integration.

Maintain an emergency local administrator or break-glass procedure. Store credentials securely, limit routine use, monitor access, and test the procedure so that it works during a directory, vCenter, or network outage.

Active Directory integration for ESXi

Joining an ESXi host to an Active Directory domain allows domain users and groups to authenticate for host administration. It centralizes identity management instead of requiring a separate local account for every administrator.

Prerequisites

High-level domain join workflow

1. Verify host DNS configuration, network reachability, and time synchronization.
2. Open the ESXi host authentication or directory-services configuration in the host management interface or vSphere Client.
3. Enter the Active Directory domain and credentials for an authorized join account.
4. Complete the join and confirm that the host reports domain membership.
5. Add an Active Directory user or group to the host's permissions with the required host role.
6. Test authentication and authorization with a non-break-glass domain account.

Joining a domain authenticates an identity; it does not by itself grant every administrative capability. The domain user or group must receive an appropriate role on the ESXi host. Verify both successful login and the exact actions the account can perform.

Before leaving a domain or changing domain membership, confirm that another authorized local or directory-based administrator can manage the host. Preserve emergency local administrator access, plan for the effect on existing domain permissions, and retest authentication after the change.

Practical access-control designs

Read-only auditor access

1. Create or use an approved directory audit group.
2. Assign the Read-Only role to the group at the required datacenter or folder scope.
3. Verify that members can view inventory and configuration information but cannot modify virtual machines, hosts, networks, or alarms.

Virtual machine operator access

1. Create a custom role containing only routine virtual machine operational privileges, such as approved power operations.
2. Assign the role to an operations group on a VM folder rather than on the entire vCenter inventory.
3. Confirm that the group can operate only the virtual machines in that folder and cannot reconfigure hosts, datastores, or networks.

Delegated administration for a business unit

1. Place the business unit's virtual machines in a dedicated folder or resource hierarchy.
2. Assign a business-unit administrator group a custom role on that container.
3. Enable inheritance only when child objects should receive the same delegated access.
4. Test that the group cannot manage objects belonging to another business unit.

Permission review before a change

1. Inspect existing permissions on the target object and its parent objects.
2. Identify inherited assignments that might already grant access.
3. Check the proposed user's directory-group memberships.
4. Use a group-based assignment where possible and avoid adding an unnecessary direct user permission.

Access-control design and security practices

• Apply least privilege to every role and assignment.
• Use separation of duties: distribute sensitive responsibilities among different roles or people.
• Prefer directory groups over individual permission entries.
• Keep the number of users with the Administrator role small and trusted.
• Use dedicated roles for audit-only access and routine operational tasks.
• Avoid assigning broad permissions at the vCenter root unless global access is genuinely required.
• Review permissions, role definitions, and group membership periodically.
• Record the approval, owner, scope, role, business justification, and review date for privileged assignments.
• Protect break-glass local accounts and test emergency access procedures.
• Consider strong authentication controls and, where supported by the environment, multi-factor authentication for administrative access.

Design roles around responsibilities rather than people. For example, a role called Production VM Operator communicates its purpose more clearly than a generic role called Special Access. Avoid combining unrelated duties in one role simply to reduce the number of roles.

Validation and auditing

Configuration is not complete until access is tested. Use a non-administrative account that represents the intended user or group and verify both positive and negative outcomes.

• Test each action that the role is expected to allow.
• Test actions that the role must not allow, such as host, network, datastore, or unrelated VM configuration changes.
• Confirm that the assignment applies only to the intended inventory scope.
• Review inherited permissions and group memberships when test results are unexpected.
• Review inventory permissions, role definitions, and directory-group membership during periodic audits.
• Use vSphere events and available logs to investigate authentication and authorization activity.

A denied action is useful evidence: it can show that least privilege is working. An unexpectedly allowed action is a reason to inspect inherited assignments, overlapping groups, direct user permissions, and role contents.

Troubleshooting access failures

Exam-relevant distinctions

• A privilege is one capability; a role is a collection of capabilities.
• A permission combines a user or group, a role, and an inventory object.
• Inheritance means an assignment on a parent can affect children; propagation controls whether that assignment is applied downward.
• Effective access can come from direct permissions, inherited permissions, and group memberships.
• vCenter permissions control centralized vSphere inventory access, while ESXi also maintains host-local access management.
• Joining ESXi to Active Directory enables domain authentication but does not replace assigning an appropriate host role.
• Group-based permissions generally scale and audit better than numerous direct user assignments.
• Least privilege and separation of duties reduce the impact of compromised or misused administrative accounts.

Summary

vSphere access control is a relationship among privileges, roles, identities, permissions, and inventory scope. Privileges define actions, roles bundle those actions, and permissions assign roles to users or groups on objects. The inventory hierarchy and inheritance determine where access applies.

Secure administration uses narrowly scoped custom roles, directory groups, limited Administrator access, documented approvals, periodic reviews, and representative testing. For direct ESXi administration, reliable DNS, time synchronization, domain connectivity, authorized domain joining, host permissions, and protected local emergency access are all essential.

See the access control system reference when reviewing role design, permission scope, or ESXi directory integration.