VMware ESXi and vSphere Cluster Management

Users and Groups in VMware ESXi and vCenter Server

Learn how ESXi local users, vCenter Server identities, directory groups, roles, privileges, permissions, and inheritance control vSphere access.

Why vSphere access management matters

A vSphere environment contains powerful resources: ESXi hosts, virtual machines, datastores, networks, clusters, and management services. Access management determines who can connect to those resources and which operations they can perform.

Two concepts form the foundation:

• Authentication identifies an account or user. For example, a login may be validated against a local ESXi account or a directory service.
• Authorization determines what that authenticated identity is allowed to do. Authorization is implemented with privileges, roles, permissions, and inventory-object scope.

Users and groups are identities. A role is assigned to an identity through a permission on an inventory object. The resulting privileges control actions such as viewing a virtual machine, powering it on, changing its settings, or administering a host.

For background on the platform components, see the VMware ESXi online course and adding an ESXi host to vCenter Server inventory.

ESXi and vCenter Server identity scopes

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

These systems can have different identity scopes. A local account created on an ESXi host is not automatically a vCenter Server account. Similarly, a user who can sign in to vCenter Server does not automatically receive direct login access to every ESXi host managed by vCenter Server.

Direct-access users on ESXi hosts

A direct-access user is an account defined locally on an ESXi host and used to access that host directly. The account is maintained on that individual host; creating it there does not create the same account in vCenter Server.

Local host accounts can be useful when:

• A host operates without vCenter Server.
• An administrator needs controlled emergency or break-glass access.
• Host-level maintenance must be performed while centralized management is unavailable.
• A recovery procedure requires a known local administrative path.

Local accounts should not become the normal method for day-to-day vSphere administration. Use named accounts where possible, protect privileged credentials in an approved secrets-management process, disable or remove accounts that are no longer needed, and restrict direct host access through appropriate security controls.

Conceptual local-account procedure

1. Connect to the intended ESXi host through a supported host-management interface.
2. Review existing local users and groups before making a change.
3. Create a named account only when its purpose, owner, and required access are documented.
4. Set a strong, unique credential and apply the host's account and access policies.
5. Assign only the access required for the maintenance task.
6. Test the account against the host, not against vCenter Server.
7. Disable or remove the account when the exception or maintenance window ends.

Do not rely on a shared administrator credential for routine work. Shared credentials reduce accountability and make auditing and offboarding difficult.

vCenter Server users

A vCenter Server user is an identity authenticated through the vCenter Server environment and authorized through permissions assigned to vCenter-managed inventory. The identity may be local to the vCenter identity system or supplied by an external directory service.

vCenter permissions can be applied at different inventory levels, including folders, datacenters, clusters, hosts, virtual machines, resource pools, datastores, and networks. For example, an operations group may receive a limited virtual-machine role on a folder containing production VMs, while a monitoring group receives read-only access at a datacenter level.

vCenter Server access does not automatically create direct ESXi host access. If a user signs in directly to an ESXi host, the host evaluates that login using its own recognized identities and host permissions.

Example: one user, two connection paths

Suppose alex is a local account on an ESXi host. Alex can log in directly to that host if the local account is enabled and authorized. Alex cannot sign in to vCenter Server merely because the account exists on ESXi. A corresponding vCenter-recognized identity and a vCenter permission are required.

The reverse can also occur: a directory user may be allowed to manage a virtual machine through vCenter Server but have no permission to log in directly to an ESXi host.

Directory service integration

A directory service is a centralized identity service that stores and manages users and groups. Active Directory is a commonly used enterprise directory service. Depending on the vSphere version and deployment, ESXi hosts and vCenter Server can be joined to or configured to use directory-based identity sources.

Centralized identity management provides:

• One place to create, disable, and remove accounts.
• Group-based administration instead of repeated individual permission changes.
• More consistent onboarding and offboarding.
• Improved auditability of named identities and membership changes.
• Less dependence on permanent local accounts.

Integration does not grant access by itself. A directory user or group must still receive an appropriate role through a permission on the relevant vCenter object. Likewise, directory integration on a host does not mean every directory user can administer that host.

Directory-integration checklist

• Confirm forward and reverse name resolution for the host, vCenter Server, and directory services.
• Verify time synchronization. Large time differences can break authentication protocols and certificate validation.
• Confirm network connectivity, required ports, and directory availability.
• Use an approved account or delegated process for joining or configuring the identity source.
• Test lookup of both a user and a group.
• Choose clear group names based on function and scope, such as a monitoring or backup administration group.
• Document which systems use the identity source and which permissions are assigned.
• Plan for directory outages by maintaining controlled emergency access where policy requires it.

Groups and group-based access control

Permissions should generally be assigned to groups rather than directly to individual users. Membership then becomes the normal control point for granting, changing, and removing access.

For example, create a directory group for backup administrators, assign that group a purpose-specific vCenter role, and manage membership in the directory. When an employee changes duties, update group membership instead of searching through many inventory permissions.

Common identity categories include:

• Local host groups: groups maintained on an individual ESXi host.
• vCenter-related groups: groups managed in the vCenter identity system, where supported.
• Directory-service groups: groups maintained in Active Directory or another supported external identity source.

Group-based access requires careful review. A user may receive privileges through direct membership, nested membership, multiple groups, or inherited permissions. Privileged directory groups deserve particular attention because one membership change can affect many systems.

The vSphere access-control model

The access-control chain is:

user or group → permission → role → privileges → inventory object

Permissions and inheritance

A permission is not merely a role and not merely a user. It is the assignment of a role to a user or group at a selected inventory object.

vCenter inventory is hierarchical. A permission assigned to a parent object may flow to child objects when inheritance is enabled and applicable. This is convenient for consistent administration, but a permission granted too high in the hierarchy can expose unrelated resources.

Before assigning a permission, decide:

1. Which identity or group needs access?
2. Which role contains the required privileges?
3. Which inventory object is the narrowest suitable scope?
4. Should the permission propagate to child objects?
5. Could another direct, group-based, or inherited permission change the effective result?

For a practical permission workflow, see assigning permissions.

Roles and privileges

A role is a defined set of privileges. A privilege is a granular authorization to perform a particular operation. After a role is assigned through a permission, its privileges determine what the identity can do on the selected object.

Broad administrative roles simplify management but can permit far more than a person needs. Limited operational roles are safer for monitoring, VM operations, backup, network, storage, and other specialized duties.

Built-in and custom roles

Use a built-in role when it accurately matches the task and organizational policy. Create a custom role when the built-in choices are too broad or do not express a clear operational responsibility.

Examples include:

• A read-only monitoring role that can view health and configuration but cannot change resources.
• A VM operator role that permits approved power actions without permitting arbitrary configuration changes.
• A backup administration role containing only the privileges required by the backup workflow.
• Separate network or storage administration roles for specialized teams.

Custom-role procedure

1. Write the task the role must support and identify its owner.
2. Start with no privileges or the narrowest suitable built-in role.
3. Add only the privileges required for the documented workflow.
4. Assign the role to a test group and apply it to a non-production scope.
5. Test both allowed and denied actions with a non-administrative account.
6. Document the role purpose, privilege list, scope, and review date.
7. Promote the role only after validation and change approval.

See creating a custom role for related role-management practice.

Administrative privileges and Domain Administrators

Some vSphere deployments have historically granted broad or full administrative access to members of the Active Directory Domain Administrators group when directory integration and default permission behavior were configured in particular ways. This can affect ESXi hosts and virtual machines managed through vCenter Server.

Do not assume that this behavior is universal. Effective access must be validated against the installed vSphere version, identity-source configuration, default permissions, explicit assignments, group nesting, and inheritance settings.

Broad membership in Domain Administrators creates substantial exposure: compromise of one highly privileged directory account can become compromise of virtualization management and the workloads it controls. Review membership regularly and use delegated, purpose-specific administrative groups where policy allows. Separate directory administration, vSphere administration, backup, network, and storage responsibilities when practical.

Identity source and access design

Operational access-management practices

1. Use named accounts instead of shared administrator credentials whenever possible.
2. Assign permissions to functional groups and document the owner of each group.
3. Apply least privilege: grant only the minimum access needed for a defined task.
4. Use the narrowest practical inventory scope and review inheritance.
5. Separate duties among virtualization, directory, network, storage, backup, and security administrators where feasible.
6. Review permissions, nested group membership, and privileged groups on a scheduled basis.
7. Remove stale accounts and revoke access promptly during role changes and offboarding.
8. Document exceptions, emergency accounts, role definitions, and approval records.
9. Maintain controlled break-glass access and regularly verify that the recovery procedure works.
10. Review authentication events, audit logs, permission changes, and group-membership changes as part of security operations.

Conceptual vCenter permission workflow

1. Select the inventory object that should be managed.
2. Select the user or group from the applicable identity source.
3. Choose a built-in or tested custom role.
4. Decide whether the permission should propagate to child objects.
5. Record the business purpose, approver, scope, and review date.
6. Test effective access with a non-administrative account.

Use a test account to confirm both positive and negative behavior: it should be able to perform approved actions and should be denied actions outside its role. Avoid testing only with an administrator account because administrative privileges can hide permission-design errors.

Troubleshooting access problems

Direct ESXi access works, but vCenter Server access fails

Likely causes include a local-only ESXi account, an identity that is absent from the configured vCenter identity source, or a missing vCenter permission.

• Confirm whether the login targets the ESXi host or vCenter Server.
• Identify the authentication source used by the account.
• Verify that the user or group is recognized by vCenter Server.
• Review the assigned vCenter role and inventory scope.

vCenter login works, but an expected action is denied

The role may lack a required privilege, the permission may be assigned at the wrong object, inheritance may not reach the target, or a recent group-membership change may not yet be recognized.

• Inspect effective permissions on the target object.
• Compare the required operation with the role's privilege list.
• Check parent permissions and inheritance settings.
• Validate group membership and identity-source health.

Directory users or groups cannot be found

Check whether identity-source integration is complete. Verify DNS, time synchronization, network reachability, directory availability, configured credentials, and the ability to query the required user or group.

Unexpectedly broad administrative access appears

Review membership in Domain Administrators and other privileged nested groups. Then inspect permissions at parent inventory objects and evaluate inherited roles. Replace broad access with delegated groups and narrower scopes where policy permits.

A direct-access account cannot log in to ESXi

Confirm that the account exists and is enabled on the intended host, that the credentials are correct, and that the login is directed to the ESXi host rather than vCenter Server. Also review account lockout, access restrictions, and any host security or lockdown configuration.

Key takeaways

• Authentication identifies an identity; authorization determines its allowed actions.
• Local ESXi users and vCenter Server users belong to independent identity scopes.
• Direct host access and access through vCenter Server can produce different results for the same person.
• Directory integration centralizes identity lifecycle management but does not grant permissions automatically.
• Groups, roles, permissions, privileges, inventory objects, and inheritance work together to define access.
• Use least privilege, named accounts, delegated groups, controlled emergency access, and regular reviews.
• Validate default administrative behavior against the installed vSphere version and actual configuration, especially for Domain Administrators.