Escolar Documentos
Profissional Documentos
Cultura Documentos
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
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.
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.
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)
Token
OS
Login
(Token)
vCenter 1
Authenticate
vCenter Single Sign-On
users
Login
(Token)
vCenter 2
Login
(Token)
vCenter
Orchestrator
Login
(Token)
Authenticate Local
vCenter Single Sign-On
users
Login
(Token)
vSphere
Data
Protection
vCloud
Director
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.
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
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
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
vCenter Single Sign-On
(local to vCenter Server)
Multisite
vCenter Single Sign-On
(local to vCenter Server)
Single Pane of
Glass View?
Yes
Yes
Linked Mode?
No
Centralized
vCenter Single Sign-On
(separate to vCenter Server)
Figure 3. Workflow Process Determining the Appropriate vCenter Single Sign-On Deployment Configuration
Basic
vCenter Single Sign-On
(local to vCenter Server)
Multisite
vCenter Single Sign-On
(local to vCenter Server)
Centralized
vCenter Single Sign-On
(separate to vCenter Server)
vSphere HA
vSphere HA
Availability
Availability
vCenter
Single Sign-On
High Availability
vCenter Server
Heartbeat
vCenter Server
Heartbeat
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).
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.
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.
NOTE: Thanks to Alan Renouf for providing the VMware Labs vCenter 5.1 Pre-Install Check Script.
vCenter
Inventory Svc
vCenter
Server
vSphere
Web Client
Basic vCenter
Single Sign-On
Server
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.
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
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.
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
vCenter Server Heartbeat
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)
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
vCenter Server Heartbeat
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
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)
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).
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
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.
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: 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.
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