Managing vCenter Users, Roles and Permissions
Learn how to control administrator access in VMware vCenter Server by managing identity sources, creating roles, assigning privileges and applying permissions to inventory objects.
In a VMware vSphere environment, not every administrator or support engineer needs full access to vCenter Server. A virtualization team may need permission to manage virtual machines, a storage team may need datastore visibility, and a help-desk operator may only need to view inventory and console status. VMware vCenter Server provides a role-based permissions model that lets administrators grant the access required for each responsibility.
1. Understand vCenter Users, Roles and Permissions
vCenter authorization is based on assigning a role to a user or group at an inventory object. The role contains the privileges that determine what the account can do. Permissions can be applied at different levels of the vSphere inventory hierarchy and can be configured to propagate to child objects.
User or Group
The identity receiving access. It can be a local vCenter identity or an account/group from a configured identity source, depending on the deployment and version.
Privilege
A specific permitted action, such as powering on a virtual machine, creating a snapshot, modifying a datastore or managing permissions.
Role
A named collection of privileges. Roles make it easier to apply consistent permission sets to different users and groups.
Permission
The assignment connecting a user or group to a role on a selected inventory object, optionally propagating to child objects.
For example, assign a group named VM-Operators a custom role on a specific cluster or VM folder. Members receive the privileges in that role on the selected object and, if propagation is enabled, applicable child objects.
2. Users, Groups and Identity Sources
Before assigning a permission, make sure the user or group exists in an identity source that vCenter can use. Available identity-management options depend on vCenter Server version, deployment configuration and authentication architecture.
- vCenter Single Sign-On (SSO) users and groups: Accounts and groups in the vCenter SSO domain, commonly
vsphere.localin many installations. - External identity providers: Accounts and groups from configured identity sources, such as Active Directory over LDAP or supported federated identity providers, depending on the vCenter release.
- Local appliance accounts: Local operating-system accounts used for appliance administration are distinct from SSO identities and should not automatically be treated as vCenter inventory users.
Where to manage SSO users and groups
- Sign in to the vSphere Client using an account with the required SSO administration privileges.
- Open Administration and locate the Single Sign On area.
- Open Users and Groups to review or manage SSO-domain identities, where the controls are available.
- Use Identity Sources to review configured external identity providers.
Menu labels and exact navigation can differ between releases. The account used to manage SSO identities must have the appropriate SSO administrative rights.
3. Understand Built-in and Custom Roles
vCenter includes predefined roles for common administration tasks. They provide a starting point, but many organizations create custom roles so that access matches operational responsibilities.
| Role | General purpose | Typical use |
|---|---|---|
| No Access | Explicitly denies access to the assigned object through that permission. | Restricting visibility; use carefully with inherited permissions. |
| Read-only | Allows viewing inventory and configuration information without making changes. | Auditors, monitoring teams and read-only support staff. |
| Administrator | Provides broad administrative privileges across the assigned scope. | Trusted vCenter administrators; tightly control membership. |
| Virtual Machine Power User | Provides a predefined set of virtual-machine interaction and management privileges. | Operations staff who need more than basic viewing. |
| Virtual Machine User | Provides a more limited set of virtual-machine interaction privileges. | Users who need to interact with assigned VMs. |
Built-in role names and exact privilege membership can vary by vCenter release. Review the privilege list in your own environment before assigning a role in production.
4. Create a Custom Role in vCenter
A custom role is useful when built-in roles grant too much or too little access. For example, a service-desk group might need to power on, power off and open the console of virtual machines without being allowed to delete VMs or modify host networking.
Sign in to vCenter using an account authorized to manage roles and permissions.
Open Administration, then locate the access-control or roles management section. In many vSphere Client releases, roles are managed under Access Control → Roles.
Select the create-role action, provide a clear name such as VM-Operator-Custom, and add a description of its purpose.
Expand privilege categories and choose only the actions needed. Avoid enabling broad permissions simply to make a task work.
Confirm the selected privileges and save. Review it with a test account before assigning it to a production group.
VM-Power-Operator, VM-Console-Only or Datastore-ReadOnly. Keep a record of why each privilege is included.5. Assign Users and Groups to Roles
After creating or selecting a role, assign it to a user or group on the inventory object where the permissions should apply.
Select the vCenter Server, datacenter, cluster, host, VM folder, virtual machine, datastore or network object.
Go to the object’s Permissions tab. Depending on the client release, you may need to open the Configure area first.
Select Add Permission or the equivalent action, then choose the relevant identity source and search for the user or group.
Choose the built-in or custom role that matches the user’s job responsibilities.
Enable Propagate to children when the permission should apply to applicable child inventory objects. Leave it disabled when access should be limited to the selected object, subject to object-type behaviour.
Confirm the permission appears in the object’s permissions list, then test with the intended user account.
6. Permission Propagation and Inheritance
Propagation determines whether a permission assigned to an inventory object is inherited by its child objects. For example, a permission assigned to a VM folder with propagation enabled can apply to virtual machines contained in that folder.
| Assignment scope | Example | Potential effect |
|---|---|---|
| vCenter Server | Permission on the vCenter root object | Can affect a broad portion of inventory when propagated. |
| Datacenter | Permission on one datacenter | Can apply to its child inventory objects when propagated. |
| Cluster or host | Permission on a selected cluster or standalone host | Scopes access to that compute area and applicable children. |
| VM folder | Permission on an application VM folder | Can grant access to VMs organized under that folder. |
| Individual VM | Permission on one virtual machine | Provides a narrow scope for a specific workload. |
For example, if a cluster contains separate Finance, HR and Development VM folders, assigning a role to the Finance folder is usually better scoped than assigning it at the vCenter root. This reduces unnecessary access to unrelated workloads.
7. Practical Role Design Examples
| Team | Suggested role design | Recommended scope |
|---|---|---|
| Virtualization administrators | Administrator or a carefully designed infrastructure-admin role | Only the vCenter objects they manage. |
| Service desk | Custom VM interaction role with required console and power actions | Assigned VM folders or specific VMs. |
| Auditors | Read-only | Relevant datacenter or vCenter inventory scope. |
| Application owners | Custom role limited to approved VM operations | Application-specific VM folder or VMs. |
| Storage operations | Custom datastore role with required monitoring or management privileges | Relevant datastores and storage objects. |
These are role-design examples, not fixed privilege recipes. Determine exact privileges from the tasks the team must perform and verify the result in a non-production environment.
8. vCenter Permissions Best Practices
- Apply least privilege: Grant only privileges required for assigned responsibilities.
- Use groups: Manage access through identity-provider groups where practical. This simplifies onboarding and offboarding.
- Avoid routine use of Administrator: Reserve highly privileged accounts for approved tasks and emergency use.
- Scope permissions narrowly: Assign permissions to the smallest appropriate inventory object.
- Document custom roles: Record each role’s purpose, owner and privilege rationale.
- Review propagation: Understand which child objects inherit access before enabling it.
- Audit access regularly: Review direct and group-based assignments, stale accounts and excessive privileges.
- Test before production: Validate role behaviour with a test account and representative inventory objects.
- Protect privileged identities: Use strong authentication and follow privileged-access management policies.
9. Troubleshooting Common Permission Problems
| Symptom | Possible cause | What to check |
|---|---|---|
| User cannot see an inventory object | Missing view privileges, wrong scope or identity resolution issue | Check role, group membership, identity source and inherited permissions. |
| User can view a VM but cannot power it on | Role lacks required VM interaction privileges | Review virtual-machine privileges and permission scope. |
| Permission works on one VM but not another | Different folder placement or permission inheritance | Compare inventory paths and effective permissions. |
| New group member has no expected access | Group membership or identity synchronization issue | Verify membership at the identity provider and re-authenticate as appropriate. |
| User unexpectedly has broad access | Another direct or inherited permission grants privileges | Inspect parent-object permissions and relevant group memberships. |
Conclusion
Managing users, roles and permissions is a core vCenter administration responsibility. A well-designed role-based access model gives virtualization, storage, application and support teams the access they need without exposing the entire virtual infrastructure to every account.
Start by understanding the difference between privileges, roles and permissions. Use identity-provider groups, create custom roles for specific tasks, assign permissions at the narrowest practical inventory scope and verify effective access with test accounts. Regular reviews help keep your vSphere environment secure as teams and workloads change.