5.8

ESXi 5.5 is not integrated with vCenter Single Sign-On, and ESXi users cannot be created with the vSphere
Web Client. ESXi users must be created and administered with the vSphere Client. vCenter Server is not
aware of users that are local to ESXi. In addition, ESXi is not aware of vCenter Server users. However, Single
Sign-On can be configured to use an Active Directory domain as an identity source and the ESXi host can be
configured to point to the same Active Directory domain to obtain user and group information. This action
allows the same set of users to be available to the host and to vCenter Server.
In vCenter Single Sign-On 5.5, the way that vCenter Single Sign-On is deployed and the type of user who
installs vCenter Single Sign-On no longer affects which administrator user accounts have privileges on the
Single Sign-On server and on vCenter Server. During the vCenter Server installation process, certain users
are granted privileges to log in to vCenter Server and certain users are granted privileges to manage vCenter
Single Sign-On. The vCenter Server administrator might not be the same user as the vCenter Single Sign-On
administrator. This means that when a user logs in to the vSphere Web Client as the default Single Sign-On
administrator ([e-mail]), they might not see any vCenter Server systems in the
inventory. The inventory appears to be empty because the only see the systems upon which they have
privileges in the vSphere Web Client.
This also means that when an operator logs in to the vSphere Web Client as the default vCenter Server
administrator, they might not see the vCenter Single Sign-On configuration tool. The configuration tool is
not present because only the default vCenter Single Sign-On Administrator ([e-mail]) is
allowed to view and manage vCenter Single Sign-On after installation. The Single Sign-On administrator
can create additional administrator users if necessary.
A conflict might occur if Local OS users cannot be seen or if there is a multiple site or node configuration
issue. In that case, the identity source must be configured, or SSO must be used with vsphere.local domain
authentication.
After SSO is installed (no matter the configuration), validate the identity sources which are configured so
that they are both present and accurate to the way that authentication should proceed. Note that there is
only one default domain in Single Sign-On 5.5, and as a result choose the most frequently logged into
domain as the default domain.
Single Sign-On provides several different deployment methods to best suit your environment.
Basic deployment
A single standalone instance of vCenter Single Sign-On supports the
connectivity of identity sources and is installed on the same host as vCenter
Server. This type of deployment meets the requirements of most users.
Multiple instances in the
same location
Multiple vCenter Single Sign-On nodes are installed at a local site and
configured for high availability. In vSphere 5.5, vCenter Single Sign-On has
its own Directory Service that automatically replicates information to other
vCenter Single Sign-On nodes in the environment.
Multiple instances in
different locations
vCenter Single Sign-On nodes are installed at geographically separate sites.
Each site has one or more vCenter Single Sign-On installations and data is
replicated between sites. Multi-site deployment is required if configuring
Linked Mode vCenter Server instances across sites.
The following vCloud Suite components support vCenter Single Sign-On:
n
vCenter Server
n
vCenter Orchestrator
n
vCloud Automation Center
n
vCloud Director
n
vCloud Networking and Security
n
vSphere Big Data Extensions
vCloud Suite Architecture Overview and Use Cases
40 VMware, Inc.