Information Technology Reference
In-Depth Information
Once again using the AAA model as a rough structure for the security discussion, we'll start
with a review of vCenter Server authentication.
Authenticating Users with Single Sign-On
As with ESXi, users will need to authenticate to get access to vCenter Server in order to perform
any tasks, but the process for how this authentication works changed signii cantly from
vSphere 5.1 with the introduction of vCenter Single Sign-On. How you handle that authentica-
tion depends on your environment. Both the Windows Server-based version of vCenter Server
and the Linux-based vCenter Server virtual appliance offer the same authentication mecha-
nisms. Generally you will probably authenticate against Active Directory, although you could
manage users and groups locally within Single Sign-On itself or even connect it to OpenLDAP.
Because using Active Directory and using local SSO users are the most common methods of
authentication, we'll focus on these for this discussion.
In the following sections, we'll cover these three topics:
Coni guring Single Sign-On for authentication against Active Directory
◆
Coni guring Single Sign-On for authentication against local users
◆
Understanding how vCenter Server authenticates against ESXi with vpxuser
◆
Configuring SSO on Windows Server for Active Directory
In previous version of vSphere, when vCenter is installed on a Windows Server computer, lever-
aging Active Directory is pretty simple: Join the computer to an Active Directory domain before
installing vCenter, and vCenter would—by virtue of how Windows integrates with Active
Directory—automatically be able to take advantage of users and groups stored within Active
Directory. If you choose not to join Active Directory, then the Windows-based version of vCen-
ter will need to be coni gured for use with an external directory service.
vSphere 5.1 introduced SSO for the i rst time, and VMware has made some additional
changes in vSphere 5.5. The key to SSO and Active Directory integration is the SSO administra-
tor, or “master,” account. This account can be used to coni gure all additional directory services
post installation.
When installing vCenter, you will be asked which user or group should be added as a vCen-
ter administrator. By default, the built-in SSO
administrator@vsphere.local us
er account
will be used. These default settings in SSO do not by default extend permissions to users
within Active Directory. This is a good thing; we don't want to add users who aren't necessarily
involved in the administration of the vSphere environment. Generally speaking, you want to
assign a permission to only those users who actually need it; this is part of the
principle
of
least
privilege
, a key concept in computer security.
The issue is this: Prior to vSphere .5.5, by default, the domain Administrators group—this
is the Active Directory Administrators group—was given the Administrator role in vCenter
Server (we'll discuss vCenter Server roles in more detail in the section “Managing vCenter Server
Permissions” later in this chapter). This permission assignment happened at the vCenter Server
object and was propagated down to all child objects. It has been our experience that in many
organizations there are members of the Administrators group who don't have anything to do
with the virtualization infrastructure. Granting those users privileges inside vCenter Server is a
