Although day-to-day vSphere management operations are usually done on vCenter Server logged in through the vSphere Client, there are instances when users must work with ESXi directly, such as with configuration backup and log file access. Then there are monitoring solutions, which sometimes require direct access to the ESXi host; these would typically be configured to use service accounts. Prior to ESXi 4.1, you could only create local users, which each had separate locally-stored passwords per host. Since this is cumbersome and doesn’t scale, we decided to address this in the vSphere 4.1 release.
With ESXi 4.1, you can configure the host to join an Active Directory domain, and any user trying to access the host will automatically be authenticated against the centralized user directory. Any time you are asked to provide credentials (e.g., logging in directly to the ESXi host using vSphere Client, or running a vCLI command or script), you can enter the username and password of a user in the domain to which the host is joined. The big advantage of this is that you can now continue to manage user accounts using Active Directory, which is significantly easier and more secure than trying to manage accounts independently on a per-host basis.
You can still have local users defined and managed on a host-by-host basis and configured using the vSphere client, vCLI or PowerCLI. This can be used in place of, or in addition to, the Active Directory integration. I'm not sure if there is really a good reason to do this if the host is already joined to an AD domain, but this capability is available.
The only user defined by default on the system is the root user. The initial root password is typically set using the Direct Console User Interface (DCUI). It can be changed afterward using the vSphere client, vCLI or PowerCLI. Note that root is the one user that’s only defined locally; in other words, the root password is not ever mapped to an Active Directory account. You can use the vSphere Client, vCLI (the vicfg-user command), or PowerCLI to manage the root password.
There are also local roles, similar to vCenter Server roles, which define things that the user is authorized to do on the host. For instance, a user can be granted read-only access, which allows them only to view host information; or they can be granted administrator access, which allows them both to view and to modify host configuration. The three built-in roles are Administrator, Read-only, and No Access (this last one is what most users have by default). Although you can create custom roles, you’d have to create them separately on each ESXi, and so you’d probably want a good reason to go beyond the built-in roles.
If the host is integrated with Active Directory, local roles can also be granted to Active Directory users and groups. For example, an Active Directory group can be created to include users who should have an administrator role on a subset of ESXi servers. On those servers, the administrator role can be granted to that Active Directory group; for all other servers, those users would not have an administrator role. ESXi 4.1 also automatically grants administrator access to the Active Directory group named “ESX Admins,” which allows the creation of a global administrators group. (If you want to override this behavior, simply configure the roles on the ESXi host to give the “No Access” role to the “ESX Admins” group — this will override the default behavior).
The following video (courtesy of VMware video training author David Davis) goes over the Active Directory integration feature in ESXi 4.1.
Here are some other useful blog entries that go into some depth on this feature.
