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 T A T 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
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
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 client’s 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 only—not 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 environment’s 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-On–enabled solutions to access within the vSphere environment.
vCenter
Single
Sign-On
vSphere Data
Protection
vShield
Manager
vCenter
Orchestrator
Browser
Log
vSphere
Web Client
vCenter
Inventory
Service
vCloud
Director*
2012
* 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 visitor’s 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 user’s 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 server’s 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 instances—with 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.
vCenter 1 vSphere Web Client
vCenter 2 OrchestratorvCenter vSphere Data Protection vCloud Director 1 2 3 3 3 4 5 6 7 8 9 Login (user, pwd) Issue Token (user, pswd) Token Login
(Token) (Token)Login (Token)Login (Token)Login (Token)Login
Authenticate vCenter Single Sign-On users
Authenticate Local vCenter Single Sign-On users
Authenticate
OS
vCenter Single Sign-On
AD
(Domain 1) (Domain 1)AD LDAPOpen
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 high-availability backup node. It is not possible to add multiple high-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 ✔
vCenter Single Sign-On Deployment Single vCenter Server Multiple vCenter Servers Multiple Geographical Locations? Single Pane of
Glass View? Single Pane ofGlass View?
Linked Mode?
Centralized vCenter Single Sign-On (separate to vCenter Server) Multisite
vCenter Single Sign-On (local to vCenter Server) Basic
vCenter Single Sign-On (local to vCenter Server)
Multiple Sites: Yes Requirement: Linked Mode No Yes No Yes Yes No Multiple Sites: No 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-On–enabled 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 passthrough–capable 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.
vCenter Server Heartbeat vCenter Server
Heartbeat 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)
Availability vSphere HA vCenter Single Sign-On High Availability Availability vSphere HA
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 source—Active Directory domain—of 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 server–defined 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 user’s 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.
vCenter Single Sign-On
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 later—for 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
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 Database
vCenter Server Host or Virtual Machine
vCenter Server vCenter Inventory Svc vSphere Web Client Basic vCenter Single Sign-On Server
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 1–1,000 hosts/1–10,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
vCenter Server
Los Angeles
New York
Miami
vCenter Server Host or Virtual Machine
vCenter Inventory Svc vSphere Web Client Basic vCenter Single Sign-On Server vCenter Server
vCenter Server Host or Virtual Machine
vCenter Inventory Svc vSphere Web Client Basic vCenter Single Sign-On Server vCenter Server
vCenter Server Host or Virtual Machine
vCenter Inventory Svc vSphere Web Client 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 1–1,000 hosts/1–10,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 instances—recommended for more than six local vCenter Server instances in a single datacenter,
metropolitan or campus-style environment—VMware 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.
vSphere Web Client Basic vCenter Single Sign-On Server Local vCenter Single Sign-On Database
vCenter Server 2
vCenter
Server
Database
Server
vCenter Server 2vCenter
Server
vCenter Server 2vCenter
Server
Inventory Svc vCloud Director B2, B2, B3 Inventory Svc Inventory SvcFigure 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)
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.
Los Angeles
vCenter Server vCenter Server vCenter Inventory Svc vSphere Web Client Primary vCenter Single Sign-On Server vCenter Server vCenter Inventory Svc vSphere Web Client Multisite vCenter Single Sign-On ServerNew York
Miami
vCenter Server vCenter Server Local Databases vCenter Server vCenter Inventory Svc vSphere Web Client Multisite vCenter Single Sign-On ServerFigure 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
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 host’s 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 it—including
vCenter Single Sign-On itself—uses 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 nodes—one 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 balancer–related 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 server–enabled 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 configuration—primary or multisite. After the updated vCenter Single Sign-On server configuration has been deployed, reregister all vCenter Single Sign-On server–enabled 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.
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 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.
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:
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 Server—release 5.1 update 1a—all 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.
• 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>
• 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 system’s host name contains unsupported characters. An error message appears and vCenter Single Sign-On installation fails when the vCenter Single Sign-On system’s 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 informa-tion 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.
• 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.
• 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 user’s 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.
