VMware ESXi and vSphere Cluster Management

Users and Groups in VMware vSphere and ESXi

Learn how ESXi users, vCenter identities, Active Directory groups, roles, privileges, and permissions control VMware access.

VMware vSphere access is based on four related concepts: users, groups, privileges, and roles. Together, they determine who can connect to VMware infrastructure and which actions that person can perform.

Authentication verifies an identity, such as a username and password. Authorization determines what that authenticated identity is allowed to do. A successful login does not automatically provide permission to configure hosts, manage virtual machines, or change access settings.

ESXi Hosts and vCenter Server Have Different Administrative Scopes

An ESXi host is the VMware hypervisor system that runs virtual machines. A vCenter Server is the centralized management platform for ESXi hosts and the virtual infrastructure inventory.

When an administrator connects directly to an ESXi host, access is evaluated in that host's local security context. When an administrator connects to vCenter Server, access is evaluated against vCenter inventory objects such as datacenters, clusters, hosts, virtual machines, folders, and resource pools.

This distinction is fundamental: an account that works on one ESXi host is not automatically a vCenter account, and vCenter access does not automatically create a local account on every managed host.

Direct-Access Users on ESXi Hosts

A direct-access user is a user account defined and maintained locally on an individual ESXi host. The account can be used to connect directly to that host through an applicable management interface and perform actions allowed by its host permissions.

  • A local account belongs to the specific ESXi host where it was created.
  • The same username on another host is a separate account, even if the names and passwords match.
  • A local ESXi account is not automatically available in vCenter Server.
  • The account must receive appropriate host-level permissions or a role before it can perform administrative actions.

Typical Uses for Local ESXi Accounts

Local accounts can be useful for host-level administration, emergency access, recovery when vCenter Server is unavailable, or small environments that do not use centralized identity integration. A controlled local account can provide break-glass access: emergency access reserved for restoring management or resolving a serious outage.

Local accounts should be limited, protected, monitored, and reviewed. Avoid creating separate permanent accounts for every routine task when directory-based group access through vCenter can provide centralized lifecycle management.

Managing Local ESXi Users and Groups

Use the ESXi host management interface appropriate to your vSphere release to view local users and groups. The usual workflow is to select the host's local security or users-and-groups area, then create, modify, disable, or remove accounts as required.

  1. Connect to the specific ESXi host using an authorized administrative identity.
  2. Open the host's local users and groups management area.
  3. Review existing accounts and groups before creating a new identity.
  4. Create or modify the account, applying a strong credential and an appropriate lifecycle state.
  5. Assign a host-level role or permission that contains only the required privileges.
  6. Test the account with a non-destructive action and record the ownership and purpose of the account.

vCenter Server Users

A vCenter Server user is an identity granted access within the vCenter Server management environment. The identity may be a local vCenter identity or an identity supplied by a configured directory service such as Microsoft Active Directory.

vCenter permissions can be assigned to inventory objects including:

  • Datacenters
  • Clusters
  • ESXi hosts
  • Virtual machines
  • Folders
  • Resource pools

Centralized vCenter access allows an administrator to manage multiple hosts and virtual machines through one management plane. The administrator's effective access depends on the permissions assigned at the relevant inventory scope.

vCenter user access is managed separately from local accounts on individual ESXi hosts. A person can have permission to operate virtual machines through vCenter without having direct host-level login access.

Direct ESXi and vCenter Identities Are Independent

Direct-access ESXi users and vCenter Server users belong to separate identity contexts. Consider a person who has a local account on Host A but is not a member of any user or group granted vCenter permissions. That person may be able to connect directly to Host A but will not automatically be able to sign in to vCenter Server.

The reverse is also true. A user with vCenter permissions may be able to manage a host or virtual machine through vCenter without possessing a local ESXi account for direct host access.

Characteristic | Direct-access ESXi user | vCenter Server user

Where the identity is defined | Locally on one ESXi host, or through an identity source configured for that host | In the vCenter identity context, often using a local identity or directory identity

Primary access target | The individual ESXi host | vCenter Server and its managed inventory

Administrative scope | Host-level actions and settings | Datacenters, clusters, hosts, virtual machines, folders, and resource pools within assigned scope

Relationship to other hosts | Not automatically available on other ESXi hosts | Can provide centralized access across multiple managed hosts when permissions allow

Relationship to vCenter | Does not automatically grant vCenter access | Does not necessarily grant direct host login access

Common uses | Host recovery, emergency access, and standalone host administration | Centralized administration, delegated operations, auditing, and inventory management

Directory considerations | Directory integration must be configured and validated for the host | Directory or identity-source integration must be configured and validated for vCenter

This separation matters during access design and troubleshooting. Always identify the connection target first: the ESXi host or vCenter Server. Then determine which identity source and permission assignments apply to that target.

Directory Service Integration

A directory service is a centralized identity system that stores and manages users, groups, and authentication information. Microsoft Active Directory is a common example in vSphere environments.

Directory integration can allow vCenter Server and ESXi hosts to recognize organizational users and groups instead of requiring every administrator to have a separate local account. This provides several advantages:

  • Centralized account creation, modification, disabling, and removal
  • Group-based assignment aligned with job responsibilities
  • Fewer long-lived local accounts
  • More consistent access when staff or responsibilities change
  • Improved ability to review and audit membership and permissions

Integration is configured for each applicable platform or scope. Configuring vCenter Server to use Active Directory does not, by itself, configure every ESXi host for directory authentication. Likewise, a host's directory configuration should not be assumed to apply to vCenter.

Directory Integration Workflow

  1. Confirm the directory prerequisites, including network connectivity, DNS name resolution, and synchronized time.
  2. Configure the identity source or directory relationship on the applicable vCenter Server or ESXi host.
  3. Verify that known directory users and groups can be looked up.
  4. Test authentication with a noncritical directory account or test group.
  5. Assign permissions to a narrowly scoped directory group rather than immediately granting broad access to a large production group.
  6. Test the effective permissions and document the configuration.

Active Directory Administrative Access Considerations

In some historical vSphere and ESXi configurations, members of the Active Directory Domain Admins group receive broad administrative privileges over ESXi hosts and virtual machines managed through vCenter Server. Domain Admins is a highly privileged directory group, so its virtualization implications must be treated as a security concern.

Do not assume that this behavior is identical in every vSphere release, identity configuration, or permission model. Confirm the effective permissions and version-specific behavior in the environment being assessed before making access-control decisions.

As part of a security review:

  • Determine whether Domain Admins or another broad directory group has a VMware administrative assignment.
  • Review permissions at the root, datacenter, cluster, host, folder, and virtual-machine levels.
  • Check whether permissions are inherited by large portions of the inventory.
  • Compare actual effective access with the access required by the group's business purpose.
  • Replace broad implicit or inherited access with narrowly scoped virtualization groups where practical.

Using a highly privileged domain group for virtualization administration can create excessive access, increase the impact of a compromised directory account, and make separation of duties difficult. Virtualization administration should normally use dedicated groups with clearly defined membership and scope.

Roles, Privileges, and Permissions

A privilege is one permitted action, such as changing a virtual machine setting or managing a host configuration. A role is a named collection of privileges. A permission links a user or group to a role on an inventory object or target scope.

Access-control element | Purpose | Example

User | Represents an individual identity | A named administrator

Group | Represents multiple identities managed together | A virtualization-operators directory group

Privilege | Defines one permitted action | Power on a virtual machine

Role | Combines related privileges into a reusable access profile | A custom VM-operator role

Permission | Assigns a user or group a role on an object | Operators group assigned the VM-operator role on a folder

Inventory object | Defines where the permission applies | A datacenter, cluster, host, folder, or VM

Inherited permission | Carries a parent assignment to child objects | A datacenter permission applying to its clusters and VMs

Permission Inheritance

Permission inheritance is the propagation of a permission from a parent inventory object to its child objects. For example, a group assigned a role at a datacenter level may receive that role on child clusters, hosts, folders, and virtual machines when inheritance is enabled and no applicable limitation or override prevents it.

Inheritance simplifies administration, but a high-level assignment can grant access more broadly than intended. Review both the assignment point and the resulting effective access on target objects.

Built-In and Custom Roles

Built-in administrative roles provide predefined privilege collections for common management needs. Custom roles can be designed for operational duties such as routine virtual machine operations, read-only auditing, backup integration, or monitoring.

Use the principle of least privilege: grant only the access required for a person's or service's assigned task. Avoid giving a VM operator host-configuration privileges or permission-management privileges unless those duties are explicitly required.

Managing Permissions in vCenter Server

  1. Select the inventory object that should be the permission scope.
  2. Open the object's permissions management area.
  3. Add a permission and select the applicable user or group from the configured identity source.
  4. Select a built-in or custom role.
  5. Choose whether the assignment should propagate to child objects through inheritance.
  6. Review the resulting access at the target object and at relevant child objects.
  7. Test a representative permitted action and a representative denied action.

When access does not behave as expected, inspect permissions at the target object and its parent objects. Also review group membership, inherited assignments, role contents, and any more specific permission that affects the user.

Planning User and Group Access

Begin by deciding which activities require direct ESXi access and which should be performed centrally through vCenter Server. Most routine administration can use vCenter identities and directory groups, while a small number of controlled local accounts can be retained for host recovery.

Define access requirements by job function:

  • Administrators: Full infrastructure duties only where required, with carefully controlled membership.
  • Operators: Routine virtual machine and operational tasks without unnecessary host or permission-management privileges.
  • Auditors: Read-only access to the required inventory and configuration information.
  • Backup services: Only the privileges needed by the backup workflow, preferably through a dedicated service identity.
  • Application or monitoring services: Narrow, documented permissions with no interactive administrative access unless required.

Use groups to represent job functions rather than assigning privileges directly to named people. For example, a directory group for virtualization operators can receive a custom role on a VM folder. Membership changes then update access without redesigning permissions for every individual.

Administrative need | Recommended identity approach | Suggested role scope | Security consideration

Routine centralized administration | Directory group through vCenter | Datacenter or cluster scope as required | Review inheritance and keep administrator membership small

Host emergency access | Designated local ESXi break-glass account | Single-host administrative scope | Protect credentials, monitor use, and test recovery procedures

Virtual machine operations | Dedicated directory operations group | VM folder or selected VM scope | Exclude host configuration and permission-management privileges

Read-only auditing | Directory auditor group | Required inventory scope with read-only role | Prevent configuration changes and review visibility requirements

Backup or monitoring integration | Dedicated service identity or group | Only the privileges required by the integration | Document ownership, rotate credentials, and avoid broad administrator roles

Review permissions regularly, especially after staff changes, directory-group changes, inventory restructuring, or changes to operational responsibilities. Include local ESXi accounts, vCenter assignments, inherited permissions, and highly privileged directory groups in the review.

Troubleshooting Identity and Permission Problems

A User Can Log In Directly to ESXi but Cannot Access vCenter

  • The account may exist only as a local direct-access account on that ESXi host.
  • No vCenter permission may be assigned to the user or one of the user's groups.
  • The user may be selecting the wrong authentication domain or identity source.

Confirm whether the account is local or directory-sourced, review vCenter permissions and inherited permissions for the target inventory, and verify group membership and identity-source configuration.

A User Has vCenter Access but Cannot Perform an Expected Action

  • The assigned role may not include the required privilege.
  • The permission may be assigned at the wrong inventory scope.
  • Inheritance may be disabled, or a more specific permission may affect the user.
  • The target object may be outside the assignment's scope.

Inspect the role's privileges, review permissions on the target and parent objects, and verify the user's effective access through direct and group membership.

Directory Users or Groups Cannot Be Selected or Authenticated

  • Directory integration may be incomplete or unavailable.
  • DNS, time synchronization, or network connectivity may prevent directory communication.
  • The configured identity source may be unable to resolve the requested group.

Check identity-source status, name resolution, synchronized time, network connectivity, group lookup, and authentication with a known test account.

Unexpected Users Have Broad VMware Access

  • A highly privileged directory group may have been assigned an administrative role.
  • A permission at a high inventory level may be inherited broadly.
  • Historical Domain Admins behavior may not have been reviewed for the current release and configuration.

Audit administrator-group membership, inspect root-level and datacenter-level permissions, check inheritance, and confirm effective permissions using the specific vSphere release and configuration.

Exam-Relevant Notes

  • A local ESXi user is specific to an individual host and does not automatically exist on another host.
  • An ESXi local account does not inherently grant access to the vCenter Server managing that host.
  • vCenter permissions apply to inventory objects and can be inherited by child objects.
  • A role is a collection of privileges; a permission assigns that role to a user or group on an object.
  • Directory integration must be configured and validated for each applicable platform or scope.
  • Group-based assignments generally support better lifecycle management than assignments to individual users.
  • Broad Domain Admins access must be reviewed rather than assumed, because behavior depends on release and configuration.
  • Least privilege and controlled break-glass access are complementary parts of a secure design.

Summary

vSphere access is governed by identity, authorization, and scope. Direct-access users are local to individual ESXi hosts, while vCenter Server users operate within centralized inventory permissions. Active Directory and other directory services can centralize identity and group management, but each applicable platform must be integrated and tested independently.

Reliable access design combines dedicated directory groups, carefully scoped roles, deliberate inheritance, regular reviews, and protected local emergency access. For the related access-control model, see Users and Groups.