Authentication and Authorization for ESX/ESXi and vCenter Server
Several server-side mechanisms interactively authenticate a human user when a client application, such as the vSphere Client or a vSphere Web Services SDK application, connects to the server. Because ESX/ESXi uses Linux-based authentication, and vCenter Server is a Windows service, the two systems use different approaches for handling user accounts. Managed Objects for Handling User Accounts shows the two different user management mechanisms associated with the VMware vSphere server.
Managed Objects for Handling User Accounts
These services work together to ensure that only authenticated users can connect to ESX/ESXi or vCenter Server systems, and that they can access only those objects—folders, virtual machines, datacenters, virtual services, and so on—for which they have the required privileges and which they are authorized to use or to view.
In addition, the vSphere Web Services SDK supports automated login through a credential store. See Using the Credential Store for Automated Login.
ESX/ESXi User Model
When users enter their user account and credential from a client application, the server consults the appropriate user account store and validates the authenticity of the user account and the associated credential. Currently, the credential consists of a password, but vSphere also supports certificates, such as X.509 certificates. Authenticated users can then access objects they are authorized to use. Authentication succeeds if a user identity exists as a user account on the target system or in a supported directory service.
ESX/ESXi leverages standard Linux infrastructure, including the Linux pluggable authentication module (PAM) mechanism for user account creation and management. The VMware authentication daemon (vmware-authd) is implemented as a PAM module. You can create and manage user accounts on an ESX/ESXi system by using HostLocalAccountManager.
vCenter Server User Model
vCenter Server is a Windows-based service that uses native Windows facilities and the Windows user model for identification and authentication. The vCenter Server Web service is associated with the Windows user account that was logged in to the machine for the vCenter Server installation process. This vCenter Server administrator account must be a member of the local Windows Administrator group on the machine. VMware recommends creating a dedicated Windows user account for installing and managing the vCenter Server system.
Other vCenter Server users who connect to the Web service must also have a Windows account on the local Administrator group.
For details, see the Datacenter Administration Guide in the VMware vSphere documentation set.
Organizations that are using Microsoft Active Directory can use the user identities contained in a Windows 2003 Server domain controller or Active Directory service across their virtual infrastructure. Microsoft Active Directory identities are supported for all clients that run vSphere Web Services SDK applications from Windows-based systems.
VMware vSphere Web Services SDK client applications can use SSPI to authenticate to the local machine and establish a remote connection. See the vSphere API Reference for more information.
vSphere Security Model
While the details of authentication and authorization differ between ESX/ESXi and vCenter Server, the model itself is the same for both system. It relies on privileges, roles, and permissions.
A privilege is a system-defined requirement associated with a VMware vSphere object. Privileges are defined by VMware. Privileges are static, and do not change for a single version of a product. Each managed object has one or more privileges that a principal (user, group member) must have to invoke an operation or to view a property. For example, managed entities such as Folder and VirtualMachine require the principal to have the System.Read privilege on the entity to view the values of its properties.
The vSphere API Reference includes information about privileges required to invoke operations and to view properties on the Required Privileges labels on the documentation page for each managed object. Privileges for vSphere components are defined as follows:
For example:
A privilege might be specific to vCenter Server or to ESX/ESXi systems. For example, the Alarm.Create privilege is defined on vCenter Server. Setting alarms is done through the AlarmManager service interface, which requires a running vCenter Server system.
Privilege requirements apply to system objects regardless of how a given client application attempts to access server content (vSphere Client, CLI, or SDK). For example, you can use the following URL to access virtual machine datastore files:
The URL accesses a Datastore object in the inventory. You must have privileges to access each object in the hierarchy, corresponding to the elements of the URL.
A role is a predefined set of privileges. Users are granted privileges to objects through roles (see Using Roles to Consolidate Sets of Privileges). When you assign a user or group permissions, you pair the user or group with a role and associate that pairing with an inventory object. A single user might have different roles for different objects in the inventory.
For example, if you have two resource pools in your inventory, Pool A and Pool B, you might assign a particular user the role Virtual Machine User on Pool A and the role ReadOnly on Pool B. These assignments allow that user to turn on virtual machines in Pool A. In Pool B, the user can view the status of virtual machines, but cannot turn on virtual machines.
Privileges Granted to the Administrator Role shows a complete list of privileges encompassed by the Administrator role as defined on a vCenter Server 4.0 system.
In vSphere, a permission consists of a user or group and an assigned role for an inventory object, such as a virtual machine or ESX/ESXi host. Permissions grant users the right to perform the activities specified by the role on the object to which the role is assigned.
For example, to configure memory for an ESX/ESXi host, a user must be granted a role that includes the Host.Configuration.Memory privilege. By assigning different roles to users or groups for different objects, you can control the tasks that users can perform in your vSphere environment.
Many tasks require permissions on more than one object.
Setting Up Users, Groups, and Permissions
Setting up users, groups, and permissions consists of these tasks:
At runtime, use SessionManager to log in to the server. The SessionManager.Login method requires a user ID and password and determines what that session can access on the server.