When it comes to ESX Server, authentication is driven by the Service Console (also known as the Console OS, or COS). Since the Service Console is based on Red Hat Enterprise Linux, then Linux-centered authentication models reign here. This means that, by default, users must be defined and managed locally on each ESX server. In small implementations, this may not be a big deal; in larger implementations, however, this quickly becomes unwieldy.
Fortunately, ESX Server provides a method to help deal with part of this overhead. The esxcfg-auth command allows administrators to configure the ESX Server authentication mechanisms to integrate (partially, at least) with Active Directory so that administrators can use their Active Directory usernames and passwords to log in to ESX Server. Be aware, however, that this integration is only partial--while account passwords are pulled from Active Directory, the actual accounts
VirtualCenter brings a new level of intelligence to managing the virtualization infrastructure. Whereas ESX Server relies upon Linux-centric authentication methods, VirtualCenter--as a Windows-based server--links directly into Active Directory. This means that organizations using Active Directory to manage user accounts can bring those objects directly into VirtualCenter. Both Active Directory-based users as well as groups can be granted permissions within VirtualCenter.
VirtualCenter brings more to the table than just Active Directory integration, though; it also provides very granular role-based access control. Organizations define roles and associate very specific permissions with those roles. For example, an organization may have server operators that need the ability to power on, power off, and interact with virtual machines, but not modify their configuration. This is all possible through VirtualCenter, and this gives organizations deploying VI3 much greater flexibility in managing the virtual infrastructure components.
On the back-end, though, VirtualCenter still uses the Linux-centric authentication methods in order to communicate with ESX Server. In fact, when an ESX host is added to VirtualCenter, VirtualCenter creates a Linux user that it uses when connecting to ESX Server (recall that you must supply the root password when adding an ESX host to VirtualCenter). In this way, VirtualCenter acts as a bridge, or a proxy, between Active Directory and the Linux-centric methods of the ESX Server Service Console.
Virtual Infrastructure (VI) Client
By and large, it's pretty clear that VirtualCenter and ESX Server use very different authentication methods. What muddies the waters, though, is the fact that users can use the same application--the Virtual Infrastructure (VI) Client--for managing both components of VI3. The fact that the VI Client can connect to a VirtualCenter server (and thus needs Active Directory credentials) as well as directly to an ESX Server host (and thus needs Service Console/Linux credentials) leads to the question, "Which username and password do I use?"
Unfortunately, today there is no easy or simple answer. Using esxcfg-auth to integrate the Service Console, even if only partially, into Active Directory eases the pain somewhat, and allows users to use their Active Directory username and password for both the VI client (when connecting to the VirtualCenter server) and the Service Console (when using SSH or SFTP/SCP). Using the VI client to connect directly to the ESX Server, though, still requires root access in most instances.
Fortunately, VMware has designed Virtual Infrastructure 3 so that the vast majority of all tasks that an administrator needs to perform can be done with the VI client connected to VirtualCenter, so the need to use SSH or the VI client connected to ESX Server should be few and far between. For those few remaining tasks, the use of esxcfg-auth helps further reduce any authentication confusion.
Scott Lowe has had a lifelong love of computers, dating all the way back to his first computer, a Tandy TRS-80 Color Computer. He began working professionally in the technology field in 1994, and has since held the roles of an instructor, technical trainer, server/network administrator, systems engineer, IT manager, and CTO. For the last few years, Scott has worked as a senior systems engineer with a reseller, providing technology solutions to enterprise customers. Scott also runs a virtualization-centric weblog at http://blog.scottlowe.org.
This was first published in November 2007