VMware VCenter Server Single Sign On

VMware vCenter
Single Sign-On Server
Technical White Paper

T E C H N I C A L M A R K E T I N G D O C U M E N TAT I O N
V 1 . 0 /A U G U S T 2 0 1 3 /J U S T I N K I N G
VMware vCenter Single Sign-On Server
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
vCenter Single Sign-On Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Deployment Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Basic Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Primary Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
High-Availability Backup Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Multisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
vCenter Single Sign-On Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
vSphere High Availability (vSphere HA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
vCenter Server Heartbeat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
vCenter Single Sign-On High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
vCenter Single Sign-On Pre-Install Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Microsoft Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
vCenter Server Users and Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
SSL Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Microsoft SQL Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
vCenter Single Sign-On. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
vCenter Single Sign-On Reference Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Recommendation A: Single vCenter Server Environment . . . . . . . . . . . . . . . . . . . . . . . . 14
Recommendation B: Multiple vCenter Server Instances. . . . . . . . . . . . . . . . . . . . . . . . . . 14
Recommendation B: Optional Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Recommendation C: Multiple vCenter Server Instances in Linked Mode. . . . . . . . . . . 17
Additional vCenter Single Sign-On Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Postinstallation Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Default Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Adding Administrators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Updating Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Using Network Load Balancers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Changing vCenter Single Sign-On Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 20
Changing vCenter Single Sign-On Passwords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Backup and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Known Issues with Workarounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
TECH N I C AL WH ITE PAPE R / 2
Introduction
With the release of VMware vSphere 5.1, which introduces several key components on which vSphere
depends, customers are required to modify their traditional upgrade procedures.
The focus of this paper is the VMware vCenter Single Sign-On server component of
VMware vCenter Server 5.1. This new authentication service requires that a user understand its
operations and use cases before planning a vSphere 5.1 installation or upgrade.
Early adopters of vCenter Server 5.1 have asked a number of questions about various vCenter Single Sign-On
deployment configurations. Common deployment configurations will be explained in detail, including several
reference architectures for successful deployment of vCenter Single Sign-On server.
Background
vCenter Single Sign-On is a new component introduced with vCenter Server 5.1 to provide centralized
authentication services to vCenter Server, as well as other VMware technologies designed to integrate or coexist
with vCenter Server.
vCenter Single Sign-On has been created to simplify the configuration of user access within the vSphere
environment by offloading the authentication requirements of multiple solutions to a shared framework known
as vCenter Single Sign-On.
Prior to the release of vSphere 5.1, vCenter Server instances were connected directly to a Microsoft
Active Directory domain. The vCenter Server instance passed authentication requests directly to the
Active Directory domain controller configured for authentication via its host membership.
With the release of vSphere 5.1, vCenter Single Sign-On enables vCenter Server users to authenticate
directly with multiple Active Directory forests and domains, as well as introducing support for OpenLDAP
directory services.
vCenter Single Sign-On can provide its own authentication resources by enabling administrators to create and
define users, groups and policies that have access to vCenter Single Sign-On registered solutions.
vCenter Single Sign-On can be viewed as an authentication broker that serves as a gateway to connected
authentication sources such as Active Directory. After successful username/password authentication,
vCenter Single Sign-On offers an extra level of security by supplying an industry-standard security token
based on SAML 2.0 and WS-Trust. This token is then used by the clients user session, providing the
necessary authentication for access to the vSphere solutions and components that are registered with
vCenter Single Sign-On within the environment. This simplifies the administration of multiple VMware solutions
by authenticating with the environment and having access to the registered solutions without having to
manually authenticate each time a solution is accessed.
The security token exchange is used for authentication onlynot for permission-based access. Each vSphere
solution continues to maintain roles and permissions.
vCenter Single Sign-On Operations

As previously mentioned, vSphere 5.1 users no longer log in directly to vCenter Server, but rather to an
authentication domain defined by their vSphere environments vCenter Single Sign-On server. This
authentication domain is defined as @system-domain and does not support editing or customizing. Solutions
and components are registered with vCenter Single Sign-On server during their installation or upgrade process.
They provide a way for vSphere solutions to validate the security tokens issued for authentication. They also
maintain a registry of vCenter Single Sign-Onenabled solutions to access within the vSphere environment.
2012
vCenter
Inventory
Service
vSphere
Web Client
vShield
Manager
vCenter
Single
Sign-On
vCenter
Orchestrator
Log
Browser
vCloud
Director*
vSphere Data
Protection
* vCloud Director is partially integrated with
vCenter Single Sign-On; only provider-side logins
can be integrated with vCenter Single Sign-On.
Figure 1. vCenter Single Sign-On Enabled Solutions
The role of vCenter Single Sign-On server is similar to that of a security guard in the lobby of a large office
building. In this analogy, a visitor establishes their identity to the security guard, who validates it against a
visitors list. When identity is confirmed, a temporary pass or keycard is issued, which enables entrance past
security and further into the building. But there are multiple offices, each with its own locking door that either
allows or denies access. A visitors temporary pass or keycard is valid only for a limited period of time, enabling
access to specific floors and offices.
vCenter Single Sign-On links user logins with group information via access to identity sources such as
Active Directory domains. The user and group membership information is passed to the various solutions and
components registered with vCenter Single Sign-On server. These solutions then use this information to
determine actual access for a given user to that particular solution. In this way, vCenter Single Sign-On does not
determine a users actual ability to use a specific component. Instead, it provides a uniform, centralized method
for correlating user information with group membership for all registered products. These products can then use
this information to determine actual user permissions.
If a user has two individual vCenter Single Sign-On environments that have the same identity sources
configured, authentication across vCenter Single Sign-On domains is not allowed because token exchange is
unique to each vCenter Single Sign-On servers authentication domain. With vSphere 5.1, there are no trusts or
linking of vCenter Single Sign-On servers. This is particularly important when services or solutions connecting
to multiple vCenter Server instances are required to communicate across vCenter Server instanceswith
Linked Mode, for example. We will discuss this later in the paper.
When logging in to VMware vSphere 5.1 Web Client, a user provides a username and password that are passed
as an authentication request to the vCenter Single Sign-On server. vCenter Single Sign-On, configured with
authentication sources such as Active Directory, exchanges a username and password for a security token after
successful authentication. This token is then presented when the user requests access to various vSphere
solutions and components such as vCenter Server and VMware vCenter Orchestrator, as shown in Figure 2.
AD
(Domain 1)
AD
(Domain 1)
Open
LDAP
Authenticate
2
1
Issue Token
(user, pswd)
Login
(user, pwd)
vCenter Single Sign-On
vSphere Web Client
Token
OS
Login
(Token)
vCenter 1
Authenticate
users
Login
(Token)
vCenter 2
Login
(Token)
vCenter
Orchestrator
Login
(Token)
Authenticate Local
users
Login
(Token)
vSphere
Data
Protection
vCloud
Director
Figure 2. vCenter Single Sign-On Authentication Process
By default, each provided token is valid for a given amount of time. When it is presented to each respective
solution for access, that solution validates the token with vCenter Single Sign-On and resets the time to live
(TTL) of the validated token for the solution to be accessed. After the TTL has expired, users must again
authenticate with the vCenter Single Sign-On server.
Deployment Configurations
To upgrade to a vSphere 5.1 environment, or to design a new one, particular attention must be given to the
placement and configuration of the vCenter Single Sign-On server, which can be deployed in a multitude of
configurations. It is always the first component installed, regardless of whether it is a new installation or an
upgrade from a previous vSphere version.
It is recommended that prior to installing vCenter Single Sign-On server, the multiple deployment configurations
be understood, as well as how each option can be used.
The following are the two main configurations presented during installation:
Basic Node
This is a single, standalone instance of vCenter Single Sign-On server, which is a recommended use case for
most vSphere environments. This typically is deployed in proximity to the vCenter Server instance.
Use basic node vCenter Single Sign-On server in the following scenarios:
With a single vCenter Server instance of any supported inventory size: as many as 1,000 hosts, 10,000 virtual
machines, if sized correctly
With multiple physical locations, geographically dispersed, each having vCenter Server instances and with no
requirement for single pane of glass monitoring across the multiple instances; each vCenter Server instance
with its own vCenter Single Sign-On server authentication domain at each location
With use of VMware vCenter Server Appliance
The added benefit of using vCenter Single Sign-On in basic mode is that the architecture is identical to that of
previous vCenter Server releases, but with additional local service.
Primary Node
This is a vCenter Single Sign-On server instance configured as a master node for the vCenter Single Sign-On
environment. It is required for the support of more advanced configurations such as vCenter Single Sign-On
server high-availability or multisite environments, which are discussed in the following sections.
There can be only one primary node configuration per vCenter Single Sign-On environment, and one is
required before proceeding with the deployment of vCenter Single Sign-On high-availability and remote
site architectures.
High-Availability Backup Node

This is an individual vCenter Single Sign-On server instance that is used to attach to a vCenter Single Sign-On
primary server. It can provide local failover of the vCenter Single Sign-On server authentication services when
both the primary node and high-availability node are placed behind a network load balancer that supports
SSL passthrough (for example, Apache httpd). High-availability configuration is one primary node and one highavailability backup node. It is not possible to add multiple high-availability nodes to a single primary node.
Use the high-availability backup vCenter Single Sign-On server in the following scenarios:
With multiple vCenter Server instances within close proximity or in the same physical location, connected with
reliable networking and low latency
When high availability of the vCenter Single Sign-On server is required with no plans to utilize
VMware vSphere High Availability (vSphere HA) or VMware vCenter Server Heartbeat
With one centralized vCenter Single Sign-On server where single pane of glass monitoring is required for
multiple vCenter Server instances connected locally
- Remote vCenter Server authentications are not recommended with a centralized vCenter Single Sign-On
server because of a greater dependency on WAN links as well as slow solution response times when
connecting remote vCenter Server instances.
The following section on vCenter Single Sign-On availability will discuss the additional complexity of using
vCenter Single Sign-On high availability and the limitations on actual high-availability functionality.
Multisite
This is an individual vCenter Single Sign-On server that is used to attach to a vCenter Single Sign-On primary
server and provide a local copy of the primary vCenter Single Sign-On server authentication domain at remote
locations, local to remote solutions. This enables geographically dispersed vCenter Server instances to
authenticate locally, reducing the risk involved with WAN links.
Although this approach has its advantages, it also adds complexity for the following reasons:
It does not provide site redundancy between vCenter Single Sign-On instances.
Manual export and import of the database is required between primary and all multisite nodes to maintain
database synchronization whenever an update to the vCenter Single Sign-On server identity sources,
embedded users, groups or policies occurs. Although this is not an everyday or every-week task, it maintains
synchronization of vCenter Single Sign-On users and groups. VMware provides scripts for this process.
A vCenter Server instance that connects to a local multisite vCenter Single Sign-On server instance must be a
member of the same Active Directory domain as that of the primary vCenter Single Sign-On server. It also
must have a local domain controller available.
By default, multisite mode provides only local vCenter Single Sign-On visibility, and no single pane of glass
monitoring across multiple vCenter Server instances that are geographically separated. Linked Mode is
required to maintain single pane of glass monitoring across multiple remote vCenter Server instances.
Multisite mode is purely for providing a local instance of the vCenter Single Sign-On server to authenticate
against, and it removes the risk of network outages affecting authentication outages and authentication
response times.
Multisite is required when multiple vCenter Server instances must be able to communicate with each other
for example, in Linked Mode.
Use multisite vCenter Single Sign-On server in the following scenarios:
When using Linked Mode or a third-party solution that communicates with multiple vCenter Server instances
in geographically separate sites
When it is required to have one vCenter Single Sign-On server authentication domain throughout
an organization
Comparison of Deployment Features

Basic
Primary
High Availability
Multisite
Active
Directory
Users
OpenLDAP
Users
vCenter Single
Sign-On Users
Local
Operating
System Users
Maximum
Scale
vCenter Simple
Install
Individual
Installer
vCenter on
Windows
vCenter Server
Appliance
vCenter Linked
Mode
Dedicated
Database
Shared
Database
Table 1. Comparison of Deployment ConfigurationBased Features
vCenter
Single Sign-On
Deployment
Single
vCenter
Server
Multiple
vCenter
Servers
vCenter
Server
Multiple
Geographical
Locations?
Multiple
Sites:
Yes
No
Single Pane of
Glass View?
Multiple
Sites:
No
Yes
No
Requirement:
Linked Mode
Basic
(local to vCenter Server)
Multisite
Single Pane of
Glass View?
Yes
Yes
Linked Mode?
No
Centralized
(separate to vCenter Server)
Figure 3. Workflow Process Determining the Appropriate vCenter Single Sign-On Deployment Configuration
vCenter Single Sign-On Availability

Because the vCenter Single Sign-On server provides secure authentication services to vSphere 5.1 and later
environments, it is critical to know availability options to the vCenter Single Sign-On server to prevent risk of
outages within the vSphere and VMware vCloud Suite solutions.
One typical problem scenario with vCenter Single Sign-On availability involves providing maximum effort
in making vCenter Single Sign-On server highly available for authentication requests without providing
any protection or redundancy of the vCenter Server instance itself, rendering the efforts regarding
vCenter Single Sign-On availability irrelevant. Any solution that provides for the protection of vCenter Server 5.1
can be applied to vCenter Single Sign-On server; however, there is no need to protect one without the other,
because authentication is not required if vCenter Server or other vCenter Single Sign-Onenabled solutions
become unavailable. Other VMware technologies that are enabled in vCenter Single Sign-On are still heavily
dependent on the availability and operational status of vCenter Server.
vSphere High Availability (vSphere HA)

If vSphere HA is used to protect vCenter Server, it can also protect the vCenter Single Sign-On server
component if it is local or is used with a separate vCenter Single Sign-On server virtual machine.
NOTE: Be aware of the vCenter Server startup order and dependent services when distributing components
across multiple virtual machines.
The following are affected by this:

1. vCenter Single Sign-On database
2. vCenter Single Sign-On server
3. vCenter Inventory Service
4. vCenter Server database
5. vCenter Server
6. vSphere Web Client
vCenter Server Heartbeat

For protecting vCenter Server, the current release of vCenter Server Heartbeat, v6.5.1, has been updated to
support vSphere 5.1 and all of its components, including vCenter Single Sign-On server.
vCenter Server Heartbeat supports a vCenter Single Sign-On server local to a vCenter Server instance or
separate server. No additional vCenter Server Heartbeat license is required if it is on a separate server.
vCenter Single Sign-On High Availability

If vCenter Single Sign-On server availability is required without any of the previously listed options, a
high-availability configuration can be run by placing both instances behind an SSL passthroughcapable load
balancer. Follow the steps outlined in VMware knowledge base article 2033588.
The following are limitations of vCenter Single Sign-On high availability:
The setup, configuration and troubleshooting of third-party network load balancers are not handled by
VMware support staff.
When installing vCenter Single Sign-On high availability, SSL certificates must be updated, and registered
vCenter Single Sign-On components must be repointed, to utilize the network load balancer entry point
for communications.
The high-availability backup node does not provide vCenter Single Sign-On server administration access when
failed over.
- If the primary server is lost, the high-availability server can be promoted to primary role, enabling the
administration service. Users must contact VMware support for instructions.
- Loss of vCenter Single Sign-On administration does not affect vCenter Single Sign-On
authentication operations.
- When failed over, vCenter services such as vCenter Inventory Service and vSphere Web Client are
unable to start up or be restarted without access to the vCenter Single Sign-On server
administration components.
High-availability backup nodes share the same external database as configured when installing the primary
node. The supported VMware solutions for vCenter Server database availability are vSphere HA and
vCenter Heartbeat. VMware currently does not support the use of clustered database technologies.
As a general best practices rule, VMware does not recommend this configuration. Other, more comprehensive
solutions exist that address availability of both vCenter Server and vCenter Single Sign-On.
TECH N I C AL WH ITE PAPE R / 1 0
Basic
Multisite
Centralized
(separate to vCenter Server)
vSphere HA
vSphere HA
Availability
Availability
vCenter
Single Sign-On
High Availability
vCenter Server
Heartbeat
vCenter Server
Heartbeat
Figure 4. Workflow Process Determining vCenter Single Sign-On Availability Options
vCenter Single Sign-On Pre-Install

Requirements
The installation of vSphere vCenter Sign-On is a relatively straightforward process when planned correctly.
The installation process touches many things in the environment, so it is important to review the
vCenter Single Sign-On server prerequisites prior to deployment, preferably during the initial design phase.
vCenter Single Sign-On server is the first component to be installed prior to vCenter Server installation
or upgrade.
Microsoft Active Directory

When using the Microsoft Windows Server operating system (OS), much of the vCenter Single Sign-On
server configuration is automated during the installation. This makes configuring correct access to the
identity sourceActive Directory domainof the vCenter Server critical to the success of the operation.
1.
The vCenter Single Sign-On server requires its time to be synchronized with an Active Directory
domain controller.
2.
A domain name server (DNS) must provide forward and reverse lookup resolution for the
Active Directory domain controller(s) that the vCenter Single Sign-On Server will connect to.
3.
vCenter Single Sign-On Server must check whether Active Directory utilizes secure LDAP connectivity.
If an Active Directory requires SSL, users must confirm that they have no expired certificates within the
Active Directory or vCenter Server environment. If expired SSL certificates are queried, it will prevent the
autodiscovery from completing and might lock the user out of accessing vCenter Server. Refer to
VMware knowledge base article 2034833: Implementing CA signed SSL certificates with vSphere 5.1.
4.
The machine account used for installing and configuring the vCenter Single Sign-On server has
Active Directory read-only permissions to view the user account and group membership properties
(the default policy setting for domain member machines).
5.
It is recommended that the user or service account used to install vCenter Single Sign-On server be an
Active Directory member with local OS administrator privileges.
6.
Domain rules should enable the firewall settings on the Active Directory domain controller to allow
access on ports 389 (plain LDAP), 636 (SSL LDAP), 3268 (plain Global Catalog (GC) interface), 3269
(SSL GC).
vCenter Server Users and Permissions

It is important to know where your vCenter Server user and groups reside within your environment prior to
installing vCenter Single Sign-On server.
1. Identify vCenter Server domain and local users:
The use of vCenter Server local OS user accounts (that is, host name\administrator) is possible only if
also configured locally to the vCenter Single Sign-On server. If vCenter Single Sign-On server is
installed separately from vCenter Server, these local OS users to vCenter Server will be unavailable.
It is recommended that local OS users within vCenter Server be removed and reconfigured as
vCenter Single Sign-On serverdefined users after installation of the vCenter Single Sign-On server.
2. Identify cross-domain users with vCenter permissions:
With vCenter Single Sign-On and multiple domains within a trusted Active Directory forest, there
will be challenges when authenticating users across trusted domains that are not directly attached to
vCenter Single Sign-On server. It is recommended that all trusted domains in vCenter Server be identified,
with each users domain added as a separate vCenter Single Sign-On identity source regardless of
Active Directory trusts that exist. Do not use cross-domain membership.
SSL Certificates
Organizations that require the use of self-signed certificates or the ability to use self-generated SSL certificates
to further secure communications with vCenter Single Sign-On server can find the process for configuration in
the following:
VMware knowledge base article 2035011: Configuring CA signed SSL certificates for vCenter Single Sign-On in
vCenter 5.1
It should be reviewed prior to installation.
Microsoft SQL Server

1. vCenter Single Sign-On server requires that Microsoft SQL Server be in Mixed Mode for authentication for
installation (Windows Server and SQL Server authentication). This is because the vCenter Single Sign-On
solution creates and uses SQL Server user accounts for database communications.
2. Prior to installing vCenter Single Sign-On server, create the vCenter Single Sign-On server database.
VMware has provided example scripts that can be located on the vCenter ISO. For example, to use SQL
Server, run the following scripts to create and populate the database:
<CDROM>\Single Sign-On\DBScripts\SSOServer\SQLServer\rsaIMSLiteMSSQLSetupTablespaces.sql
<CDROM>\Single Sign-On\DBScripts\SSOServer\SQLServer\rsaIMSLiteMSSQLSetupUsers.sql
NOTE: The included scripts are to guide users through the process, but they must be edited to meet password
and location requirements of a particular organization.
3. vCenter Single Sign-On server requires a JDBC connection as its database communication and TCP/IP on
the SQL Server to be enabled.

During the installation, it is required that a password be set for the admin@system-domain, which is an SSO
superuser account. The password cannot include any of the following characters:
^ (circumflex)
* (asterisk)
$ (dollar)
; (semicolon)
(double quote)
) (right parenthesis)
< (less than)
> (greater than)
& (ampersand)
| (pipe)
In some cases, a trailing space also cannot be included.
This password is also used to set the vCenter Single Sign-On master password (not the same as
admin@system-domain) and should be recorded in case it must be used laterfor recovery, for example
when the password is required. Although some of these characters can be used with the
admin@system-domain account, the master password can be unusable if unsupported characters are used.
VMware Labs (labs.vmware.com) has a vCenter 5.1 Pre-Install Check Script that verifies the previously
mentioned requirements.
Figure 5. vSphere 5.1 Pre-Install Check Utility
NOTE: Thanks to Alan Renouf for providing the VMware Labs vCenter 5.1 Pre-Install Check Script.
vCenter Single Sign-On Reference Architecture

We have explained vCenter Single Sign-On technology. We will now provide recommendations, categorized into
four straightforward models, for deploying vCenter Single Sign-On in any vCenter Server environment
regardless of complexity.
Recommendation A: Single vCenter Server Environment

When designing or planning a vCenter Single Sign-On server for a single vCenter Server instance, VMware
recommends the use of the basic configuration, installed locally to the vCenter Server instance.
vCenter
Inventory Svc
vCenter
Server
vSphere
Web Client
Basic vCenter
Single Sign-On
Server
vCenter Server Host or Virtual Machine
vCenter Database
vCenter Single Sign-On Database
Figure 6. Recommended Deployment Single vCenter Server 5.1
Benefits
There is no change to the existing architecture.
All services are local.
The database is on the same database server as that of vCenter Server(local or remote).
It supports 11,000 hosts/110,000 virtual machines when sized correctly.
It is a single virtual machine, for better availability as well as backup and restore options.
Using any other configuration for a single vCenter Server instance introduces unnecessary complexity to the
management and maintenance of vCenter Server.
Recommendation B: Multiple vCenter Server Instances

When designing or planning a vCenter Single Sign-On with multiple vCenter Server instances (local or remote), a
single vCenter Single Sign-On authentication domain typically is not required. In this case, VMware recommends
deploying each vCenter Server instance with its own vCenter Single Sign-On server in basic mode and local to
the vCenter Server instance as described in Recommendation A.
Los Angeles
New York
vCenter
Inventory Svc
vCenter
Server
vSphere
Web Client
Miami
vCenter
Inventory Svc
vCenter
Server
vSphere
Web Client
vCenter
Inventory Svc
vCenter
Server
vSphere
Web Client
Basic vCenter
Single Sign-On
Server
Basic vCenter
Single Sign-On
Server
Basic vCenter
Single Sign-On
Server
Figure 7. Recommended Deployment Multiple vCenter Server 5.1 Instances
Benefits
There is no change to the architecture.
All vCenter Server instances are independent of each other.
All services are local to vCenter Server.
The database is on the same database server as that of vCenter Server.
It supports 11,000 hosts/110,000 virtual machines when sized correctly.
It is a single virtual machine, for better availability as well as backup and restore options.
It maintains standard deployment configuration throughout the organization.
Recommendation B: Optional Configuration

Optionally, when designing or planning a vCenter Single Sign-On server with many local vCenter Server
instancesrecommended for more than six local vCenter Server instances in a single datacenter,
metropolitan or campus-style environmentVMware supports the use of a centralized model built around
the basic-configuration vCenter Single Sign-On server installed separately on a dedicated virtual machine.
This eliminates the multiple administration points of vCenter Single Sign-On for multiple vCenter Server
instances and provides a single URL for vSphere Web Client access.
Basic vCenter
Single Sign-On
Server
vSphere
Web Client
Local vCenter
Single Sign-On Database
Database
Server
vCenter
Server
vCenter
Server
vCenter
Server
vCloud Director
B2, B2, B3
Inventory Svc
Inventory Svc
Inventory Svc
vCenter Server 2
vCenter Server 2
vCenter Server 2
Figure 8. Optional Deployment Multiple vCenter Server 5.1 Instances in a Single Location
Benefits
It provides centralized vCenter Single Sign-On authentication.
- For the same physical location
- For metropolitan/campus
- Recommended for six or more local vCenter Server instances
It offers centralized vSphere Web Client for vCenter Single Sign-On administration.
It provides single pane of glass monitoring across all vCenter Server instances (without Linked Mode).
It provides ease of availability.
- Same as vCenter Server
vSphere HA
It is a separate server.
- To maintain authentications in case of a single vCenter Server outage
- Local database to encapsulate vCenter Single Sign-On for ease of availability and recovery
options (optional)
Recommendation C: Multiple vCenter Server Instances in Linked Mode

When designing or planning a vCenter Single Sign-On configuration with multiple remote vCenter Server
instances in Linked Mode, or third-party solutions that require communications across multiple vCenter Server
instances, VMware recommends deploying vCenter Single Sign-On in a multisite configuration where one site is
configured as primary and the other sites configured as multisite vCenter Single Sign-On servers.
New York
vCenter
Inventory Svc
vCenter
Server
vSphere
Web Client
Primary
vCenter Single
Sign-On Server
vCenter Server
Miami
Los Angeles
vCenter
Inventory Svc
vCenter
Server
Local
Databases
vSphere
Web Client
Multisite
vCenter Single
Sign-On Server
vCenter
Inventory Svc
vCenter
Server
vSphere
Web Client
Multisite
vCenter Single
Sign-On Server
vCenter Server
vCenter Server
Figure 9. Recommended Deployment Multiple vCenter Server 5.1 Instances in Linked Mode
Benefits
Centralized vCenter Single Sign-On authentication domain
- Local to each vCenter Server location
Availability
- Same as vCenter Server
vSphere HA
Local to vCenter Server (unless there are multiple vCenter Server instances)
- Removes risk of authentication outages by providing local authentication
- Database on same database server as that of vCenter Server
Additional vCenter Single Sign-On Tasks

After vCenter Single Sign-On has been designed and optionally deployed within an environment, there are some
common operational tasks that might be required when it is operational.
Postinstallation Checks
Confirm that identity sources have been added:
During the installation of vCenter Single Sign-On server, a background task runs and attempts to automatically
add the hosts Active Directory information as an identity source. If this task fails due to directory permissions, or
if a user is working in a multidomain environment, the user must log in to the vCenter Single Sign-On server and
confirm or manually add identity sources.
Procedure
1. Open vSphere Web Client (vCenter Single Sign-On administration is available only via vSphere Web Client).
2. Log in with an account that has administration rights to vCenter Single Sign-On.
3. Select Administration from the left-side options.
4. Expand vCenter Single Sign-On and select Configuration.
5. Select the Identity Source tab.
The current identity source configuration will appear. If identity sources such as Active Directory must be added,
select the plus sign and provide the necessary information.
Default Domains
Each identity source detected by vCenter Single Sign-On is associated with a domain. Users can specify one
or more default domains. vCenter Single Sign-On uses default domains to authenticate users when a username
is provided without a domain name. If a username exists in more than one of the specified default domains,
vCenter Single Sign-On attempts to authenticate the user against each domain in the order listed.
Authentication succeeds with the first domain that accepts the credentials provided by the user. By default,
vCenter Single Sign-On first validates the user against the local OS identity source.
Procedure
1. Browse to Administration > Sign-On and Discovery > Configuration in vSphere Web Client.
2. On the Identity Sources tab, select a domain and click Add to Default Domains.
3. Click the Save icon.
4. The domain is added to the list of default domains.
5. (Optional) To change the order of the default domains, use the Move Up and Move Down arrows and
click Save.
Adding Administrators
Users who are allowed to manage the vCenter Single Sign-On server can be assigned administrator privileges.
These users might differ from those that administer vCenter Server.
Prerequisites
Ensure that you have vCenter Single Sign-On administrator privileges.
Procedure
1. Browse to Administration > Access > SSO Users and Groups in the vSphere Web Client.
2. Click the Groups tab and click Group Administrators.
3. Click Add Principals. A principal is a member of the group.
4. Select the identity source that contains the user to add to the administrators group.
5. (Optional) Enter a search term and click Search.
6. Select the user and click Add. You can simultaneously add multiple users to a group.
7. Click OK.
The user with vCenter Single Sign-On administrator privileges appears in the lower panel of the Groups tab.
Updating Certificates
When installing vCenter Single Sign-On, each component that registers with itincluding
vCenter Single Sign-On itselfuses SSL to communicate between components and registered solutions.
By default, the SSL certificates are autogenerated by VMware during the installation and upgrade process
and are sufficient for the operational security for most VMware customers.
Some customers prefer to use their own self-signed or purchased SSL certificates. A tool has been developed to
assist with the insertion of these certificates after vCenter Server installation. Due to the additional knowledge
required to create and install self-signed certificates, we recommend reviewing the following VMware knowledge
base articles:
Deploying and using the SSL Certificate Automation Tool
(VMware knowledge base article 2041600)
Generating certificates for use with the VMware SSL Certificate Automation Tool
(VMware knowledge base article 2044696)
Using Network Load Balancers

Users can configure any SSL-aware load balancer, physical or virtual, to act as load-balancing software with
vCenter Single Sign-On, thereby increasing availability. Define four paths in the load balancer configuration, one
for each vCenter Single Sign-On interface:
STS
Group check
Lookup service (all high-availability nodes)
vCenter Single Sign-On administration SDK (primary node only)
Sensitive information such as passwords is transferred to and from vCenter Single Sign-On. Configure the
Apache HTTPD software for SSL, and use only SSL ports as proxies to vCenter Single Sign-On server.
Prerequisites
NOTE: This is an example of configuring load-balancing software using Apache HTTPD. Other load balancers
are configured in a different way.
Verify that there are two vCenter Single Sign-On nodesone primary and one high-availability node
with Apache HTTPD set up as a load balancer. For information about setting up load-balancing software, see
VMware knowledge base article 2034157: Setting up Apache load-balancing software with
vCenter Single Sign-On.
Procedure
1. Define the paths.
2. Configure the proxy-related and load balancerrelated directives.
3. Add the VirtualHost entry at the end of the httpd-ssl.conf file or update an existing VirtualHost entry.
NOTE: Using 64-bit Windows operating systems might produce errors. Update the following value in the conf/
extra/httpd-ssl.conf file: SSLSessionCache shmcb:C:/PROGRA\~2/Apache Software Foundation/Apache2.2/
logs/ssl_scache (5120000).
Changing vCenter Single Sign-On Server Configuration

After deploying vSphere 5.1, a scenario might occur in which users must change the deployment model for
vCenter Single Sign-On server. This might be a change in policy, an addition of vCenter Server instances or
inheriting another datacenter with its own vSphere 5.1 vCenter Server instance. Planning ahead will help
circumvent these required changes, but it is possible to rearchitect the vCenter Single Sign-On server
deployment after installation without having to start over.
After Recommendation A deployment
To change a basic node installation to a centralized vCenter Single Sign-On server configuration separate
to vCenter Server, as described in Recommendation B, deploy a separate virtual machine and deploy
vCenter Single Sign-On in basic configuration. Then, using VMware knowledge base article 2033620, reregister
all vCenter Single Sign-On serverenabled components. After all components have been reregistered with
the new vCenter Single Sign-On server, uninstall the local vCenter Single Sign-On server.
To change a basic node installation to a primary or multisite configuration, as described in Recommendation C,
uninstall the local vCenter Single Sign-On server and follow the relevant steps to reinstall vCenter Single Sign-On
server for the chosen configurationprimary or multisite. After the updated vCenter Single Sign-On server
configuration has been deployed, reregister all vCenter Single Sign-On serverenabled components using
VMware knowledge base article 2033620: Reporting and reregistering VMware vCenter server 5.1.x
and components.
Users have suggested installing each vCenter Single Sign-On instance as a primary one to help with any
unexpected outages in the environment. However, this significantly complicates ongoing environment
management because it also requires reconfiguration of each vCenter Single Sign-On instance when any
configuration option changes, such as when adding identity sources. Therefore, the basic configuration of
vCenter Single Sign-On is recommended.
Changing vCenter Single Sign-On Passwords

When installing vCenter Single Sign-On server, users are asked to provide a password for the default
vCenter Single Sign-On server administrator account (admin@system-domain). This password is also used to
set the master password for vCenter Single Sign-On. Although the password for the admin@system-domain
account can be changed with the vCenter Single Sign-On configuration within vSphere Web Client, this
does not change the master password, which is used to run advanced commands and for recovery purposes
when needed.
Master password
The original password defined for admin@system-domain will be used as the master password.
The original password defined for admin@system-domain will be required when changing the master
password for the first time or to change the current master password again.
VMware recommends that the admin@system-domain password and the master password remain in sync to
prevent unexpected results as described in the Known Issues section.
To change the master password, enter the following from a command prompt:
rsautil manage-secrets -m <old_password> -a change -N <new_password>
Administrator password
To unlock and reset the administrator account, use one of these methods:
Wait for 15 minutes. By default, the account lockout policy is set to unlock after 15 minutes. For more
information on account lockout policies for vCenter Single Sign-On, see VMware knowledge base article
2033823: Configuring and troubleshooting vCenter Single Sign-On password and lockout policies
for accounts.
Unlock the account using another session that is still logged in to the vCenter Single Sign-On server or is using
another user account with administrator privileges.
To unlock an account using another session or using another user account with administrator privileges,
complete the following steps:
Click Home.
Click Administration.
Click SSO Users and Groups.
Right-click the affected user account, such as Admin, and click Unlock.
In emergency situations or if the default policies have been changed, users can also reset the password to unlock
the account.
To reset the vCenter Single Sign-On administrator password on a Windows server, complete the
following steps:
Resetting the password also unlocks the administrator account.
Log in to the vCenter Single Sign-On server as an administrator.
Click Start > Run, type cmd, and click OK. The Command Prompt window opens.
Navigate to the SSOInstallDirectory\utils directory. By default, the installation directory is
C:\Program Files\VMware\Infrastructure\SSOServer\utils.
Run the following command:
rsautil reset-admin-password
Enter the master password when prompted.

This is the password selected for the vCenter Single Sign-On administrator during installation. If it is changed
later, the master password remains the one chosen originally. Enter the vCenter Single Sign-On administrator
name for which the password is to be reset; for example, admin. Enter the new password for the user and then
enter it again to confirm.
The message Password reset successfully should appear.

To reset the vCenter Single Sign-On administrator password on the vCenter Server Appliance, complete the
following steps:
Log in as root to the vCenter Server Appliance.
From the command line, navigate to /usr/lib/vmware-sso/utils directory.
Run the following command:
./rsautil reset-admin-password
Enter the master password when prompted.

By default, this is the root password.
Enter the vCenter Single Sign-On administrator name for which the password is to be resetfor example, admin.
Enter the new password for the user and then enter it again to confirm.
The message Password reset successfully should appear.
Backup and Recovery

If the vCenter Single Sign-On instance is corrupted, it can be restored from backup to ensure continued vSphere
access for vCenter Server and related components.
To back up the vCenter Single Sign-On configuration, complete the following steps:
1. From the Windows user interface
Go to Programs > VMware.
Right-click Generate vCenter Single Sign-On backup bundle and click Run as administrator.
2. From the command prompt
Right-click the Command Prompt icon or menu item and select Run as administrator.
Change directory to C:\Program Files\VMware\Infrastructure\SSOServer\scripts.
If vCenter Single Sign-On is installed in a location other than the default, change to the path where it
was installed.
Type cscript sso-backup.wsf /z and press Enter.
The vCenter Single Sign-On configuration is backed up to a file named Single Sign On.zip on the desktop of the
host machine. To save the .zip file in a different location, edit the C:\Program Files\VMware\Infrastructure\
SSOServer\scripts\sso-backup script and change this line from:
savedir=appshell.Namespace(DESKTOP).Self.Path
to:
savedir=path_to_file
Restoring the vCenter Single Sign-On Configuration

To restore a vCenter Single Sign-On single node or primary node instance that has become corrupt, complete
the following steps:
Prerequisites
Prepare a host machine for the restored vCenter Single Sign-On instance. The host machine can be a physical
machine or a virtual machine. It must satisfy the hardware requirements for vCenter Single Sign-On. For more
information, see the Hardware Requirements for vCenter Server, vCenter Single Sign-On, vSphere Client, and
vSphere Web Client section of the vSphere Upgrade guide.
Verify that the vCenter Single Sign-On database is accessible from the host machine.
Verify that you have the master password for the vCenter Single Sign-On instance that you are restoring.
Verify that you have the account name and password for the RSA SSPI service and vCenter Single Sign-On
service of the vCenter Single Sign-On instance that you are restoring.
Download the vCenter Server installer from the VMware Download Center to the new host machine.
Procedure
1. Copy the backup file Single Sign On.zip to the new host machine in the directory C:\Temp\SSO Recovery.
2. Rename the new host with the same fully qualified domain name (FQDN) as the vCenter Single Sign-On
server that you created the backup from.
3. If the vCenter Single Sign-On instance that you created the backup from was in a workgroup and was
installed using its IPv4 address, make sure that the new host machine has the same static IP address.
NOTE: DHCP is not supported.
4. Verify that the DNS of the new host is forward and reverse resolvable.
5. On the vCenter Single Sign-On host machine, in the vCenter Server installation directory, double-click
theautorun.exe file to start the installer.
6. Select vCenter Single Sign-On and click Install.
7. Follow the prompts in the installation wizard to choose the installer language, and agree to the end-user
patent and license agreements.
8. Select Recover installed instance of vCenter Single Sign-On from a backup.
9. Browse to and select the Single Sign On.zip file.
10. Enter the original administrator password for the old vCenter Single Sign-On instance.
NOTE: You must use the password that was created for the admin@System-Domain user when
vCenter Single Sign-On was originally installed, even if you have changed that password.
11. Make sure that the RSA SSPI service is logged in to the same account as in the vCenter Single Sign-On
instance that you created the backup from.
12. Follow the wizard prompts to complete the vCenter Single Sign-On restoration.
If there are any vCenter Single Sign-On high-availability backup nodes associated with the primary node that
you restored, make sure that the RSA SSPI service logs in to the same account in the primary node and all
high-availability backup nodes.
From vSphere Web Client, log in to the vCenter Server instances that are registered to the
vCenter Single Sign-On instance, to verify that you have working access to them.
Known Issues with Workarounds

Although this paper complies with the current version of vCenter Serverrelease 5.1 update 1aall known issues
are published with the release notes and are updated as necessary.
Installation Issues
vCenter Single Sign-On installation fails with error 32010.*
vCenter Single Sign-On installation fails with the following error:
Error 32010. Failed to create database users. There can be several reasons for
this failure. For more information, see the vmMSSQLCmd.log file in the system
temporary folder.
Also, the vCenter Single Sign-On installation rolls back when you click OK in the error message dialog box.
This issue occurs if the password set during installation does not meet the GPO policy.
Workaround: When setting your password, ensure that you meet all of the following criteria:
- Password must meet localos/AD domain GPO policy.
- Limit password length to not more than 32 characters.
- Avoid using special characters semicolon (;), double quotes (), circumflex (^), single (), and
backward slash (\) in your password.
vCenter Single Sign-On installation fails with error 29980.*
vCenter Single Sign-On installation fails with the following error:
Error 29980. The entry is not a valid port number. The port number must be a numeric
value between 1 and 65535.
This issue occurs if you do not type a valid port number in the port number field during vCenter Single Sign-On
installation and proceed with the installation.
Workaround: Reinstall vCenter Single Sign-On. During installation, type the port number in the port number
text box.
vCenter Single Sign-On installation fails with error 20003 when 32-bit Java is installed on the machine.*
When you have a 32-bit Java installed and you have the JAVA_HOME or JRE_HOME environment variable
pointing to the 32-bit location in C:\Program Files (x86)\, your vCenter Single Sign-On installation fails.
Workaround: Temporarily remove the JAVA_HOME environment variable or set it to a location that is not in
C:\Program Files (x86)\.
Unable to create a SQL Server database for vCenter Server with SQL Server 2008 R2
(VMware knowledge base article 2044492).*
On Windows 2012 or Windows 8 machines without Internet connectivity, attempts to install
vSphere Client or vCenter Single Sign-On might fail with error 28173.*
If Microsoft .NET Framework is not installed on Windows Server 2012 or Windows 8 machines, and the
machines are not connected to the Internet, attempts to install vSphere Client or vCenter Single Sign-On on
these machines might fail with an error message similar to the following:
Internal Error 28173.
Workaround: Install .NET Framework 3.5 SP1 on the machines before installing vSphere Client or
vCenter Single Sign-On.
During vCenter Single Sign-On 1.0.0 installation, a warning message is displayed.

The vCenter Single Sign-On 1.0.0 installation process automatically discovers the identity sources if you log in
as a domain user. The installer might display the following warning message if it cannot discover the
identity source:
Error 29155: Identity sources could not be discovered automatically. You can manually
add your Active Directory as an identity source after the installation by using the
vSphere Web Client.
Workaround: None.
vCenter Inventory Service fails to start on installation after rollback of vCenter Single Sign-On installation
using vCenter Simple Install.
After vCenter Single Sign-On installation rollback, if you select the new installation folder as the subfolder
under the folder used for the previous installation, vCenter Inventory Service fails to start.
For example, if the initial installation folder used is C:\Program Files\VMware\Infrastructure, and you
choose the subfolder C:\Program Files\VMware\Infrastructure\abc for the installation after
rollback, vCenter Inventory Service fails to start.
Workaround: If vCenter Single Sign-On installation rolls back using vCenter Simple Install, select the same
installation folder used for the previous installation.
vCenter Single Sign-On requires manually created database users for external database.
The Manually Created Database User check box has been removed and there is no option for the installer to
automatically create a user.
Workaround: Run the following script to manually create the database user prior to installing
vCenter Single Sign-On:
< SSOInstaller Folder >\Single Sign On\DBScripts\SSOServer\schema\< Database >\
rsaIMSLite< DB >SetupUsers.sql
Bundled database users must set a password that meets the GPO policy.
You must set your own password for RSA_USER and RSA_DBA; this password must satisfy the GPO policy.
Workaround: When setting your password, ensure that you meet all of the following criteria:
- Password must meet localos/AD domain GPO policy.
- Limit password length to 32 characters.
- Avoid using special characters semicolon (;), double quotes (), circumflex (^), single (), and
backward slash (\) in your password.
vCenter Single Sign-On server installation fails on systems running IBM DB2 9.7 Fix Pack 1 or earlier.
Components of vCenter Single Sign-On require DB2 9.7 Fix Pack 2 or later. When you attempt to install
vCenter Single Sign-On on a system running earlier versions of DB2 9.7, installation fails.
Workaround: Update the DB2 9.7 instance to Fix Pack 2 or later.
Installation fails when you install vCenter Single Sign-On with a local database on a Turkish version of
Windows Server 2008 R2 64-bit.
You might get an error (Error 20003 or 20010) when you install vCenter Single Sign-On in a Turkish Windows
environment and the database is on the local system. This error occurs when SQL Server capitalizes certain
letters, which makes the database incompatible with vCenter Single Sign-On.
Workaround:
1. Install the database on a separate system running an English version of Windows 2008 Server.
2. Run the vCenter Single Sign-On installer on the system running the Turkish version of
Windows 2008 Server.
3. Connect to the database remotely.
Installation of a vCenter Single Sign-On highavailability or recovery node fails if master password and
administrator password are different.
The following occurs when you install vCenter Single Sign-On in high-availability mode:
- When you provide the correct vCenter Single Sign-On administrator password, validation appears to be
successful, but installation fails with an error message stating that the vCenter Single Sign-On master
password is incorrect.
- When you provide the correct vCenter Single Sign-On master password, validation fails because the
installer is expecting the vCenter Single Sign-On administrator password.
The following occurs when you install vCenter Single Sign-On in recovery mode:
- When you provide the correct vCenter Single Sign-On administrator password, installation fails with an
error message stating that the vCenter Single Sign-On master password is incorrect.
- When you install vCenter Single Sign-On on a domain machine and you provide the correct
vCenter Single Sign-On master password, installation fails with an error message stating that the
Security Support Provider Interface (SSPI) service account cannot be configured because the installer is
expecting the vCenter Single Sign-On administrator password.
- When you install vCenter Single Sign-On on a workgroup machine, installation fails with an error message
stating that the vCenter Lookup Service configuration failed. The log file contains an error message stating
that the vCenter Single Sign-On administrator password is incorrect.
Workaround: Ensure that the same password is used for the vCenter Single Sign-On master password and the
vCenter Single Sign-On administrator password. You can verify the passwords using the following commands.
The default <ssoserver folder> is typically C:\Program Files\VMware\Infrastructure\
SSOServer.
- vCenter Single Sign-On master password:
<ssoserver folder>\utils>rsautil.cmd manage-secrets -a list
- vCenter Single Sign-On administrator password:
<ssoserver folder>\utils>rsautil.cmd manage-identity-sources -a list -u admin
You can set the passwords using the following commands:
- vCenter Single Sign-On master password:
<ssoserver folder>\utils\rsautil.cmd manage-secrets -a change -m <master
password> -N <new Master Password>
- vCenter Single Sign-On administrator password:
<ssoserver folder>\utils\rsautil.cmd reset-admin-password -m <master password>
-u <admin> -p <pass>
The vCenter Single Sign-On administrator password expires by default in 365 days. When you reset this
password, also reset the vCenter Single Sign-On master password to ensure that they remain the same.
Installation fails when you attempt to install vCenter Single Sign-On in an IPv6 environment
When you use the command netsh interface ipv4 uninstall with reboot in a purely IPv6 environment on
Windows 2003, 2008, or 2008 R2, vCenter Single Sign-On installation fails. The following error occurs:
Error 29114. Cannot connect to database. In addition, this error might appear in
the install.log file: Error: Failed to access configuration database: Network error
IOException: Address family not supported by protocol family: create.
Workaround: Use the FQDN or host name of the vCenter Server system. The best practice is to use the FQDN,
which works in all cases, instead of the IP address, which can change if assigned by DHCP. In addition, you must
reinstall the IPv4 interface by using the following command: netsh interface ipv4 install.
Alternatively, on Windows 2003, 2008, or 2008 R2, navigate to the Change Adapter Settings dialog box and
deselect the Internet Protocol Version 4 (TCP/IPv4) check box.
vCenter Single Sign-On database installation fails when you use a double quotation mark in
your password.
When you use a double quote character () in your vCenter Single Sign-On password, installation of
the vCenter Single Sign-On database fails. An error message appears when you install
vCenter Single Sign-On SQL Express.
Workaround: Do not use a vCenter Single Sign-On password that contains a double quotation mark.
vCenter Single Sign-On installation fails when the systems host name contains unsupported characters.
An error message appears and vCenter Single Sign-On installation fails when the vCenter Single Sign-On
systems host name contains non-ASCII or high-ASCII characters.
Workaround: Use only ASCII characters for the host names of systems where vCenter Single Sign-On
is installed.
vCenter Single Sign-On installation fails when the vCenter Single Sign-On folder name contains
unsupported characters.
An error message appears and vCenter Single Sign-On installation fails when the vCenter Single Sign-On build
folder name contains non-ASCII or high-ASCII characters.
Workaround: Use only ASCII characters for source folders that contain vCenter Single Sign-On installer files.
Connection to the SQL Server database fails during vCenter Single Sign-On installation.
The Database connection has failed error message appears when you install vCenter Single Sign-On and you
are using manually created SQL Server database users. For SQL Server databases, you must use SQL Server
authentication database users. Windows authentication users are not supported.
Workaround: Ensure that the manually created database users are using SQL Server authentication.
Insufficient privileges error occurs when you use manually created DB2 database users.
When you install vCenter Single Sign-On, and the installer requests vCenter Single Sign-On database information for existing databases, you can select the Use manually created DB users check box. If you are using a
DB2 database and have manually created users with the rsaIMSLiteDB2SetupUsers.sql script, you might
receive an error message stating that the database users do not have sufficient privileges.
Workaround: The rsaIMSLiteDB2SetupUsers.sql script, which is located in the <installation
directory>\Single Sign On\DBScripts\SSOServer\schema\db2 directory, does not include two
of the required privileges. If you use the script to manually create users, edit the script to include the
following privileges:
GRANT DBADM ON DATABASE TO USER RSA_DBA;
GRANT CREATETAB ON DATABASE TO USER RSA_USER;
Upgrading from Single Sign-On 5.1 to Single Sign-On 5.1 Update 1 for non-English locales fails with
database table error 2229.*
When you attempt to upgrade from Single Sign-On 5.1 to Single Sign-On 5.1 Update 1 for all supported
non-English locales, the upgrade fails with a database table error 2229 similar to the following:
Product: vCenter Single Sign On -- Error 2229.Database: . Table Control could
not be loaded in SQL query: SELECT `Control`, `Type`, `X`, `Y`, `Width`, `Height`,
`Attributes`, `Property`, `Text`, `Control_Next`, `Help` FROM `Control` WHERE
`Dialog_`=?.
Workaround: Follow these steps to continue with the upgrade:

- Locate log file %TEMP%vim-sso-msi.log.
- Search for the *.mst file that was used as a cache file during previous installation. For example:
c:\Windows \Installer\xxxxx.mst.
- Locate the *.mst file and delete it.

- Run the Single Sign-On upgrade again.
vCenter Single Sign-On installation fails if the installation folder has characters such as & and %.*
Attempts to install vCenter Single Sign-On in a custom location fails if the destination folder name has
characters such as % or &. An error message similar to the following is displayed:
Error 20020. Failed to update values in server.xml file
Workaround: None.
Script errors appear when upgrading vCenter Server 5.1.x to vCenter Server 5.1 Update 1a.*
If vCenter Single Sign-On, vCenter Inventory Service, and vCenter Server 5.1.x are installed on the same virtual
machine and you upgrade to vCenter Server 5.1 Update 1a, vCenter Single Sign-On upgrades first and the
system restarts. After the virtual machine restarts, the vCenter Server autorun file opens, followed by several
script errors similar to the following:
An error has occurred in the script on this page
Line: 571
Error:VC_EXPRESS is undefined
Code:0
After the script errors stop appearing, the vCenter Server installer screen does not respond to any actions
performed on it.
Workaround: After installing vCenter Single Sign-On and before restarting the virtual machine, close the
vCenter Server installer and then restart the virtual machine. After the virtual machine has started, open the
vCenter Server installer.
Upgrade of vCenter Server and vCenter Inventory Service from 5.1 to 5.1 Update 1a might fail if
vCenter Single Sign-On is not accessible during upgrade.
Attempts to upgrade vCenter Server and vCenter Inventory Service might fail if vCenter Single Sign-On is not
accessible during upgrade.
Workaround: Ensure that vCenter Single Sign-On is up and running during vCenter Server and
vCenter Inventory Service upgrade.
Active Directory users with customized UPN usernames cannot use user principal name (UPN) format
username and password to log in to vSphere Web Client and vSphere Client.
Active Directory users might have a custom suffix in their UPN instead of using the domain name as the suffix.
For example, the username alice@company.com can be customized to be alice@sales.company.com. Active
Directory users with these custom suffixes cannot log in to vSphere Web Client and vSphere Client using UPN
format username; for example, alice@sales.company.com.
Workaround: Such Active Directory users must log in to vSphere Web Client and vSphere Client using either
Windows session credentials or NetBIOS format username.
Cannot log in to vCenter Server after you replace SSL certificates.

After you replace the SSL certificates for vCenter Server, you might not be able to log in to the server because
vCenter Server is not restarted when you replace SSL certificates. You must restart the server to refresh the
certificate for vCenter Single Sign-On.
Workaround: Restart vCenter Server after you replace SSL certificates.
Java IO exception appears in log file when you start vCenter Single Sign-On on vCenter Server Appliance
When you start vCenter Single Sign-On on a vCenter Server Appliance, a Java IO exception might appear in
/var/log/vmware/sso/catalina.out.
For example:
java.io.IOException: ClientAbortException: java.net.SocketException: Broken pipe
at com.sun.xml.ws.server.SDDocumentImpl.writeTo(SDDocumentImpl.java:278)
at com.sun.xml.ws.transport.http.HttpAdapter.publishWSDL(HttpAdapter.java:539)
In addition, when you stop the vCenter Single Sign-On server on the vCenter Server Appliance, a memory leak
error might appear in /var/log/vmware/sso/catalina.out.
For example:
SEVERE: The Web application [/ims] appears to have started a thread named
[Thread-4] but has failed to stop it.
Workaround: None.
vCenter Server might fail to start or you cannot log in to vSphere Web Client after you restart the
vCenter Single Sign-On server system.
When you restart the machine where vCenter Single Sign-On is installed, changes to the system might occur;
for example, updates are applied to the operating system, the machine name changes, or the machine is
added or removed from an Active Directory domain. These changes might cause the vCenter Single Sign-On
server to become unresponsive, even though vCenter Single Sign-On is running. As a result, vCenter Server
does not start. This can also happen if you clone or change the parameters of a virtual machine where
vCenter Single Sign-On is installed; for example, the amount of RAM, the number of CPUs, the MAC address,
and so on.
Workaround: Perform the following steps:
1. On the system where vCenter Single Sign-On is installed, locate the vCenter Single Sign-On installation
directory and run the following command from the Utilities folder:
rsautil manage-secrets -a recover -m masterPassword
2. Restart the vCenter Single Sign-On service.
3. Start the vCenter Server service.
Active Directory domain to which vCenter Server system belongs does not appear in the
vCenter Single Sign-On server list of identity sources.
On Windows, if vCenter Server is installed on a machine that is joined to an Active Directory domain, the
domain users do not appear in vSphere Client or vSphere Web Client. On Linux, the Unable to retrieve domain
user error message appears.
Workaround: Configure a reverse forward lookup zone and a related pointer record; synchronize the
system clock.
- To add a reverse forward lookup zone in the DC controller, see Adding a Reverse Lookup Zone on
the Microsoft Web site.
- To synchronize the clock, see Kerberos Troubleshooting Tips on the Microsoft Web site.
Authentication fails when vCenter Single Sign-On system (system-domain) users attempt to log in to
vSphere Web Client.
The default password policy for vCenter Single Sign-On system users specifies that passwords expire in
365 days. However, vCenter Single Sign-On does not issue a warning when a users password is
approaching expiration.
Workaround: vCenter Single Sign-On administrator users can change expired passwords for system-domain
users. Request that an administrator reset your password. If you are a vCenter Single Sign-On administrator
user, use the ssopasscommand-line tool to reset the password.
On Windows:
- Open a terminal window and navigate to
C:\Program Files\VMware\Infrastructure\SSOServer\ssolscli.
- Run the following command:
ssopass <username>.
- Enter the current password for the user, even if it has expired.
- Enter the new password and enter it again for confirmation.
On Linux (vCenter Server Appliance):
- Open a terminal window and navigate to /usr/lib/vmware-sso/bin.
- Run the following command:
./ssopass <username>.
- Enter the current password for the user, even if it has expired.
- Enter the new password and enter it again for confirmation.
The tool attempts to automatically generate the LookupService URL from the current machine environment. In
case you want to provide a different URL, or if your connections to the default-picked URL cannot be
established, you can provide the URL with the --ls-url parameter.
The host name provided in the URL must match the host name provided during installation.
Cannot use Windows session authentication in vSphere Web Client when vCenter Single Sign-On is
configured for high availability.
Using Windows session authentication requires several consecutive calls to be made to vCenter Single
Sign-On, and all of the calls must go to the same server. Because the Security Token Service (STS) client does
not accept cookies that are sent from the STS, there is no guarantee that the calls will go to the same server in
a high-availability configuration.
Workaround: None.
VMware, Inc. 3401 Hillview Avenue Palo Alto CA 94304 USA Tel 877-486-9273 Fax 650-427-5001 www.vmware.com
Copyright 2013 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed
at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be
trademarks of their respective companies. Item No: VMW-TWP-vCNTR-SNGL-SIGN-ON-SRVR-USLET-101
Docsouce: OIC-12VM008.18

VMware VCenter Server Single Sign On

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

VMware VCenter Server Single Sign On

Transféré par

Droits d'auteur :

Formats disponibles

VMware vCenter

Single Sign-On Server

Technical White Paper

VMware vCenter Single Sign-On Server

TECH N I C AL WH ITE PAPE R / 2

VMware vCenter Single Sign-On Server

TECH N I C AL WH ITE PAPE R / 3

VMware vCenter Single Sign-On Server

vCenter Single Sign-On Operations

Figure 1. vCenter Single Sign-On Enabled Solutions

TECH N I C AL WH ITE PAPE R / 4

VMware vCenter Single Sign-On Server

vCenter Single Sign-On

vSphere Web Client

Figure 2. vCenter Single Sign-On Authentication Process

TECH N I C AL WH ITE PAPE R / 5

VMware vCenter Single Sign-On Server

High-Availability Backup Node

TECH N I C AL WH ITE PAPE R / 6

VMware vCenter Single Sign-On Server

TECH N I C AL WH ITE PAPE R / 7

VMware vCenter Single Sign-On Server

Comparison of Deployment Features

Table 1. Comparison of Deployment ConfigurationBased Features

TECH N I C AL WH ITE PAPE R / 8

VMware vCenter Single Sign-On Server

vCenter Single Sign-On Availability

vSphere High Availability (vSphere HA)

TECH N I C AL WH ITE PAPE R / 9

VMware vCenter Single Sign-On Server

The following are affected by this:

vCenter Server Heartbeat

vCenter Single Sign-On High Availability

TECH N I C AL WH ITE PAPE R / 1 0

VMware vCenter Single Sign-On Server

Figure 4. Workflow Process Determining vCenter Single Sign-On Availability Options

vCenter Single Sign-On Pre-Install

Microsoft Active Directory

TECH N I C AL WH ITE PAPE R / 11

VMware vCenter Single Sign-On Server

vCenter Server Users and Permissions

Microsoft SQL Server

TECH N I C AL WH ITE PAPE R / 12

VMware vCenter Single Sign-On Server

vCenter Single Sign-On

Figure 5. vSphere 5.1 Pre-Install Check Utility

TECH N I C AL WH ITE PAPE R / 13

VMware vCenter Single Sign-On Server

vCenter Single Sign-On Reference Architecture

Recommendation A: Single vCenter Server Environment

vCenter Server Host or Virtual Machine

Recommendation B: Multiple vCenter Server Instances

TECH N I C AL WH ITE PAPE R / 14

VMware vCenter Single Sign-On Server

vCenter Server Host or Virtual Machine

vCenter Server Host or Virtual Machine

vCenter Server Host or Virtual Machine

Figure 7. Recommended Deployment Multiple vCenter Server 5.1 Instances

Recommendation B: Optional Configuration

TECH N I C AL WH ITE PAPE R / 15

VMware vCenter Single Sign-On Server

TECH N I C AL WH ITE PAPE R / 1 6

VMware vCenter Single Sign-On Server

Recommendation C: Multiple vCenter Server Instances in Linked Mode