Get started Bring yourself up to speed with our introductory content.

Authentication in a VMware Infrastructure 3 (VI3) implementation

Scott Lowe investigates how authentication is handled in a VI3 implementation.

Many organizations that have implemented VMware Infrastructure 3 (VI3), including both ESX Server and VirtualCenter, but do not have a firm grasp of how these components handle authentication. Many of these organizations are not aware of the interaction (or lack of interaction) between ESX Server, VirtualCenter, and Active Directory. How do organizations get a grasp on handling authentication and security in these environments? The first step is understanding it. Let's take a closer look at how authentication is handled in a VI3 implementation.

ESX Server
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 themselves must still be created, maintained, and deleted on each ESX Server individually. Furthermore, using esxcfg-auth will allow administrators to access the Service Console via methods like SSH or SFTP/SCP, but it won't necessarily grant them access to perform VM-related tasks. Those tasks typically must be done as root.

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

Dig Deeper on VMware basics

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.