Information Technology Reference
In-Depth Information
vCenter Server Requirement
Strictly speaking, vCenter Server is not a requirement for a vSphere deployment. You can cre-
ate and run VMs without it. However, to utilize the advanced features of the vSphere product
suite—features such as vSphere Update Manager, vMotion, vSphere DRS, vSphere HA, vSphere
Distributed Switches, host profi les, and vSphere FT—vCenter Server must be licensed, installed,
and confi gured accordingly.
But what happens when the environment grows? What happens when there are 10 ESXi hosts
and 5 administrators? Now the administrative effort of maintaining all these local accounts on
the ESXi hosts becomes a signii cant burden. If a new account is needed to manage the ESXi
hosts, you must create the account on 10 different hosts. If an account password needs to change,
you must change it on 10 different hosts. Then add into this equation other VMware compo-
nents such as vCloud Director or vCenter Orchestrator, with their own possible accounts and
passwords.
vCenter—well, more accurately vCenter Single Sign-On (SSO)—addresses this problem. It is
a prerequisite for installing vCenter Server; that is, vCenter Server cannot be installed without
installing SSO i rst. We'll explain briel y how SSO works and what other software it interacts
with (both VMware and non-VMware).
Prior to vSphere 5.1, when you logged onto vCenter your authentication request was for-
warded to either the local security authority on vCenter Server's OS or Active Directory. With
SSO, the request can still end up going to Active Directory, but it can also go to a list of locally
dei ned users within SSO itself or to OpenLDAP. Generally speaking, SSO is a more secure way
of authenticating to VMware products. Notice we said products and not vSphere? That's because
SSO has hooks into vCenter, vCenter Orchestrator (vCO), vCloud Director (vCD), and vCloud
Networking and Security (vCNS). Why is this important? It means that SSO can take a single
user and provide them with access to everything they need through the virtual infrastructure
with a single username and password, and it can do so securely.
The following list outlines the steps taken when a user logs on using the vSphere Web Client
(see Figure 3.2).
1.
The vSphere Web Client presents a secure web page to log into.
2.
The username and password is issued to the SSO server (in the form of a SAML 2.0
token).
3.
The SSO server then sends a request to the relevant authentication mechanism (local, AD,
or OpenLDAP)
4.
Once authentication succeeds, SSO then passes a token to the vSphere Web Client.
5.
This token can now be used to authenticate directly with vCenter, vCO, vCNS, or vCD.
As you can see, the authentication procedure can sound more complicated than some more
traditional methods; however, all of this ends up being seamless to the end administrator who
gets access as they did before.
During the installation of SSO, which we'll detail later in this chapter, you are given three
options for the installation type. Depending on the availability requirements of your vCenter
Server installation, you may wish to make SSO available from multiple sites or highly available
