VMware vcenter Single Sign-On Server

Transcription

1 VMware Single Sign-On Technical White Paper TECHNICAL MARKETING DOCUMENTATION V 1.0/AUGUST 2013/JUSTIN KING

2 Table of Contents Introduction Background Single Sign-On Operations Deployment Configurations Basic Node Primary Node High-Availability Backup Node Multisite Single Sign-On Availability... 9 vsphere High Availability (vsphere HA) Heartbeat Single Sign-On High Availability Single Sign-On Pre-Install Requirements Microsoft Active Directory Users and Permissions SSL Certificates Microsoft SQL Single Sign-On Single Sign-On Reference Architecture Recommendation A: Single Environment Recommendation B: Multiple Instances Recommendation B: Optional Configuration Recommendation C: Multiple Instances in Linked Mode Additional Single Sign-On Tasks Postinstallation Checks Default Domains Adding Administrators Updating Certificates Using Network Load Balancers Changing Single Sign-On Configuration Changing Single Sign-On Passwords Backup and Recovery Known Issues with Workarounds TECHNICAL WHITE PAPER / 2

3 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 Single Sign-On server component of VMware 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 5.1 have asked a number of questions about various Single Sign-On deployment configurations. Common deployment configurations will be explained in detail, including several reference architectures for successful deployment of Single Sign-On server. Background Single Sign-On is a new component introduced with 5.1 to provide centralized authentication services to, as well as other VMware technologies designed to integrate or coexist with. 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 Single Sign-On. Prior to the release of vsphere 5.1, instances were connected directly to a Microsoft Active Directory domain. The 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, Single Sign-On enables users to authenticate directly with multiple Active Directory forests and domains, as well as introducing support for OpenLDAP directory services. Single Sign-On can provide its own authentication resources by enabling administrators to create and define users, groups and policies that have access to Single Sign-On registered solutions. 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, 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 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. TECHNICAL WHITE PAPER / 3

4 Single Sign-On Operations As previously mentioned, vsphere 5.1 users no longer log in directly to, but rather to an authentication domain defined by their vsphere environment s Single Sign-On server. This authentication domain is defined and does not support editing or customizing. Solutions and components are registered with 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 Single Sign-On enabled solutions to access within the vsphere environment. vsphere Web Client Inventory Service 2012 Single Sign-On vshield Manager vcloud Director* Orchestrator Log Browser vsphere Data Protection * vcloud Director is partially integrated with Single Sign-On; only provider-side logins can be integrated with Single Sign-On. Figure 1. Single Sign-On Enabled Solutions The role of 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. 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 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, 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. TECHNICAL WHITE PAPER / 4

5 If a user has two individual Single Sign-On environments that have the same identity sources configured, authentication across Single Sign-On domains is not allowed because token exchange is unique to each Single Sign-On server s authentication domain. With vsphere 5.1, there are no trusts or linking of Single Sign-On servers. This is particularly important when services or solutions connecting to multiple instances are required to communicate across 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 Single Sign-On server. 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 and VMware Orchestrator, as shown in Figure 2. AD (Domain 1) AD (Domain 1) Open LDAP 1 Login (user, pwd) vsphere Web Client 2 Issue Token (user, pswd) 4 Token 3 Authenticate Single Sign-On OS 3 3 Authenticate Single Sign-On users Authenticate Local Single Sign-On users Login (Token) 5 Login 6 Login 7 Login 8 Login 9 (Token) (Token) (Token) (Token) 1 2 Orchestrator vsphere Data Protection vcloud Director Figure 2. 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 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 Single Sign-On server. TECHNICAL WHITE PAPER / 5

6 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 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 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 Single Sign-On server, which is a recommended use case for most vsphere environments. This typically is deployed in proximity to the instance. Use basic node Single Sign-On server in the following scenarios: With a single 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 instances and with no requirement for single pane of glass monitoring across the multiple instances; each instance with its own Single Sign-On server authentication domain at each location With use of VMware Appliance The added benefit of using Single Sign-On in basic mode is that the architecture is identical to that of previous releases, but with additional local service. Primary Node This is a Single Sign-On server instance configured as a master node for the Single Sign-On environment. It is required for the support of more advanced configurations such as 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 Single Sign-On environment, and one is required before proceeding with the deployment of Single Sign-On high-availability and remote site architectures. High-Availability Backup Node This is an individual Single Sign-On server instance that is used to attach to a Single Sign-On primary server. It can provide local failover of the Single Sign-On server authentication services when both the primary node and high-availability node are placed behind a network load balancer that supports SSL passthrough (for example, Apache httpd). High-availability configuration is one primary node and one highavailability backup node. It is not possible to add multiple high-availability nodes to a single primary node. TECHNICAL WHITE PAPER / 6

7 Use the high-availability backup Single Sign-On server in the following scenarios: With multiple instances within close proximity or in the same physical location, connected with reliable networking and low latency When high availability of the Single Sign-On server is required with no plans to utilize VMware vsphere High Availability (vsphere HA) or VMware Heartbeat With one centralized Single Sign-On server where single pane of glass monitoring is required for multiple instances connected locally - Remote authentications are not recommended with a centralized Single Sign-On server because of a greater dependency on WAN links as well as slow solution response times when connecting remote instances. The following section on Single Sign-On availability will discuss the additional complexity of using Single Sign-On high availability and the limitations on actual high-availability functionality. Multisite This is an individual Single Sign-On server that is used to attach to a Single Sign-On primary server and provide a local copy of the primary Single Sign-On server authentication domain at remote locations, local to remote solutions. This enables geographically dispersed 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 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 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 Single Sign-On users and groups. VMware provides scripts for this process. A instance that connects to a local multisite Single Sign-On server instance must be a member of the same Active Directory domain as that of the primary Single Sign-On server. It also must have a local domain controller available. By default, multisite mode provides only local Single Sign-On visibility, and no single pane of glass monitoring across multiple instances that are geographically separated. Linked Mode is required to maintain single pane of glass monitoring across multiple remote instances. Multisite mode is purely for providing a local instance of the 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 instances must be able to communicate with each other for example, in Linked Mode. Use multisite Single Sign-On server in the following scenarios: When using Linked Mode or a third-party solution that communicates with multiple instances in geographically separate sites When it is required to have one Single Sign-On server authentication domain throughout an organization TECHNICAL WHITE PAPER / 7

8 Comparison of Deployment Features Basic Primary High Availability Multisite Active Directory Users OpenLDAP Users Single Sign-On Users Local Operating System Users Maximum Scale Simple Install Individual Installer on Windows Appliance Linked Mode Dedicated Database Shared Database Table 1. Comparison of Deployment Configuration Based Features TECHNICAL WHITE PAPER / 8

9 Single Sign-On Deployment Single Multiple s Multiple Geographical Locations? Multiple Sites: Yes Multiple Sites: No No Single Pane of Glass View? Yes No Single Pane of Glass View? Yes Requirement: Linked Mode Yes Linked Mode? No Basic Single Sign-On (local to ) Multisite Single Sign-On (local to ) Centralized Single Sign-On (separate to ) Figure 3. Workflow Process Determining the Appropriate Single Sign-On Deployment Configuration Single Sign-On Availability Because the Single Sign-On server provides secure authentication services to vsphere 5.1 and later environments, it is critical to know availability options to the Single Sign-On server to prevent risk of outages within the vsphere and VMware vcloud Suite solutions. One typical problem scenario with Single Sign-On availability involves providing maximum effort in making Single Sign-On server highly available for authentication requests without providing any protection or redundancy of the instance itself, rendering the efforts regarding Single Sign-On availability irrelevant. Any solution that provides for the protection of 5.1 can be applied to Single Sign-On server; however, there is no need to protect one without the other, because authentication is not required if or other Single Sign-On enabled solutions become unavailable. Other VMware technologies that are enabled in Single Sign-On are still heavily dependent on the availability and operational status of. vsphere High Availability (vsphere HA) If vsphere HA is used to protect, it can also protect the Single Sign-On server component if it is local or is used with a separate Single Sign-On server virtual machine. NOTE: Be aware of the startup order and dependent services when distributing components across multiple virtual machines. TECHNICAL WHITE PAPER / 9

10 The following are affected by this: 1. Single Sign-On database 2. Single Sign-On server 3. Inventory Service 4. database vsphere Web Client Heartbeat For protecting, the current release of Heartbeat, v6.5.1, has been updated to support vsphere 5.1 and all of its components, including Single Sign-On server. Heartbeat supports a Single Sign-On server local to a instance or separate server. No additional Heartbeat license is required if it is on a separate server. Single Sign-On High Availability If 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 The following are limitations of 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 Single Sign-On high availability, SSL certificates must be updated, and registered 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 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 Single Sign-On administration does not affect Single Sign-On authentication operations. - When failed over, services such as Inventory Service and vsphere Web Client are unable to start up or be restarted without access to the 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 database availability are vsphere HA and 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 and Single Sign-On. TECHNICAL WHITE PAPER / 10

11 Basic Single Sign-On (local to ) Multisite Single Sign-On (local to ) Centralized Single Sign-On (separate to ) vsphere HA Availability Heartbeat vsphere HA Availability Single Sign-On High Availability Heartbeat Figure 4. Workflow Process Determining Single Sign-On Availability Options Single Sign-On Pre-Install Requirements The installation of vsphere 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 Single Sign-On server prerequisites prior to deployment, preferably during the initial design phase. Single Sign-On server is the first component to be installed prior to installation or upgrade. Microsoft Active Directory When using the Microsoft Windows operating system (OS), much of the Single Sign-On server configuration is automated during the installation. This makes configuring correct access to the identity source Active Directory domain of the critical to the success of the operation. 1. The 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 Single Sign-On will connect to. 3. Single Sign-On 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 environment. If expired SSL certificates are queried, it will prevent the autodiscovery from completing and might lock the user out of accessing. Refer to VMware knowledge base article : Implementing CA signed SSL certificates with vsphere The machine account used for installing and configuring the 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 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). TECHNICAL WHITE PAPER / 11

12 Users and Permissions It is important to know where your user and groups reside within your environment prior to installing Single Sign-On server. 1. Identify domain and local users: The use of local OS user accounts (that is, host name\administrator) is possible only if also configured locally to the Single Sign-On server. If Single Sign-On server is installed separately from, these local OS users to will be unavailable. It is recommended that local OS users within be removed and reconfigured as Single Sign-On server defined users after installation of the Single Sign-On server. 2. Identify cross-domain users with permissions: With 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 Single Sign-On server. It is recommended that all trusted domains in be identified, with each user s domain added as a separate 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 Single Sign-On server can find the process for configuration in the following: VMware knowledge base article : Configuring CA signed SSL certificates for Single Sign-On in 5.1 It should be reviewed prior to installation. Microsoft SQL 1. Single Sign-On server requires that Microsoft SQL be in Mixed Mode for authentication for installation (Windows and SQL authentication). This is because the Single Sign-On solution creates and uses SQL user accounts for database communications. 2. Prior to installing Single Sign-On server, create the Single Sign-On server database. VMware has provided example scripts that can be located on the ISO. For example, to use SQL, run the following scripts to create and populate the database: <CDROM>\Single Sign-On\DBScripts\SSO\SQL\rsaIMSLiteMSSQLSetupTablespaces.sql <CDROM>\Single Sign-On\DBScripts\SSO\SQL\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. Single Sign-On server requires a JDBC connection as its database communication and TCP/IP on the SQL to be enabled. TECHNICAL WHITE PAPER / 12

13 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 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 5.1 Pre-Install Check Script that verifies the previously mentioned requirements. Figure 5. vsphere 5.1 Pre-Install Check Utility NOTE: Thanks to Alan Renouf for providing the VMware Labs 5.1 Pre-Install Check Script. TECHNICAL WHITE PAPER / 13

14 Single Sign-On Reference Architecture We have explained Single Sign-On technology. We will now provide recommendations, categorized into four straightforward models, for deploying Single Sign-On in any environment regardless of complexity. Recommendation A: Single Environment When designing or planning a Single Sign-On server for a single instance, VMware recommends the use of the basic configuration, installed locally to the instance. Inventory Svc vsphere Web Client Basic Single Sign-On Host or Virtual Machine Database Single Sign-On Database Figure 6. Recommended Deployment Single 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 (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 instance introduces unnecessary complexity to the management and maintenance of. Recommendation B: Multiple Instances When designing or planning a Single Sign-On with multiple instances (local or remote), a single Single Sign-On authentication domain typically is not required. In this case, VMware recommends deploying each instance with its own Single Sign-On server in basic mode and local to the instance as described in Recommendation A. TECHNICAL WHITE PAPER / 14

15 Los Angeles New York Miami Inventory Svc Inventory Svc Inventory Svc vsphere Web Client Basic Single Sign-On vsphere Web Client Basic Single Sign-On vsphere Web Client Basic Single Sign-On Host or Virtual Machine Host or Virtual Machine Host or Virtual Machine Figure 7. Recommended Deployment Multiple 5.1 Instances Benefits There is no change to the architecture. All instances are independent of each other. All services are local to. The database is on the same database server as that of. 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 Single Sign-On server with many local instances recommended for more than six local instances in a single datacenter, metropolitan or campus-style environment VMware supports the use of a centralized model built around the basic-configuration Single Sign-On server installed separately on a dedicated virtual machine. This eliminates the multiple administration points of Single Sign-On for multiple instances and provides a single URL for vsphere Web Client access. TECHNICAL WHITE PAPER / 15

16 Basic Single Sign-On vsphere Web Client Local Single Sign-On Database Database vcloud Director B2, B2, B3 Inventory Svc Inventory Svc Inventory Svc Figure 8. Optional Deployment Multiple 5.1 Instances in a Single Location Benefits It provides centralized Single Sign-On authentication. - For the same physical location - For metropolitan/campus - Recommended for six or more local instances It offers centralized vsphere Web Client for Single Sign-On administration. It provides single pane of glass monitoring across all instances (without Linked Mode). It provides ease of availability. - Same as vsphere HA Heartbeat It is a separate server. - To maintain authentications in case of a single outage - Local database to encapsulate Single Sign-On for ease of availability and recovery options (optional) TECHNICAL WHITE PAPER / 16

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

18 Additional Single Sign-On Tasks After 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 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 Single Sign-On server and confirm or manually add identity sources. Procedure 1. Open vsphere Web Client ( Single Sign-On administration is available only via vsphere Web Client). 2. Log in with an account that has administration rights to Single Sign-On. 3. Select Administration from the left-side options. 4. Expand 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 Single Sign-On is associated with a domain. Users can specify one or more default domains. 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, 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, 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. TECHNICAL WHITE PAPER / 18

19 Adding Administrators Users who are allowed to manage the Single Sign-On server can be assigned administrator privileges. These users might differ from those that administer. Prerequisites Ensure that you have 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 Single Sign-On administrator privileges appears in the lower panel of the Groups tab. Updating Certificates When installing Single Sign-On, each component that registers with it including 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 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 ) Generating certificates for use with the VMware SSL Certificate Automation Tool (VMware knowledge base article ) Using Network Load Balancers Users can configure any SSL-aware load balancer, physical or virtual, to act as load-balancing software with Single Sign-On, thereby increasing availability. Define four paths in the load balancer configuration, one for each Single Sign-On interface: STS Group check Lookup service (all high-availability nodes) Single Sign-On administration SDK (primary node only) Sensitive information such as passwords is transferred to and from Single Sign-On. Configure the Apache HTTPD software for SSL, and use only SSL ports as proxies to Single Sign-On server. TECHNICAL WHITE PAPER / 19

20 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 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 : Setting up Apache load-balancing software with 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 ( ). Changing Single Sign-On Configuration After deploying vsphere 5.1, a scenario might occur in which users must change the deployment model for Single Sign-On server. This might be a change in policy, an addition of instances or inheriting another datacenter with its own vsphere 5.1 instance. Planning ahead will help circumvent these required changes, but it is possible to rearchitect the 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 Single Sign-On server configuration separate to, as described in Recommendation B, deploy a separate virtual machine and deploy Single Sign-On in basic configuration. Then, using VMware knowledge base article , reregister all Single Sign-On server enabled components. After all components have been reregistered with the new Single Sign-On server, uninstall the local Single Sign-On server. To change a basic node installation to a primary or multisite configuration, as described in Recommendation C, uninstall the local Single Sign-On server and follow the relevant steps to reinstall Single Sign-On server for the chosen configuration primary or multisite. After the updated Single Sign-On server configuration has been deployed, reregister all Single Sign-On server enabled components using VMware knowledge base article : Reporting and reregistering VMware server 5.1.x and components. Users have suggested installing each 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 Single Sign-On instance when any configuration option changes, such as when adding identity sources. Therefore, the basic configuration of Single Sign-On is recommended. Changing Single Sign-On Passwords When installing Single Sign-On server, users are asked to provide a password for the default Single Sign-On server administrator account (admin@system-domain). This password is also used to set the master password for Single Sign-On. Although the password for the admin@system-domain account can be changed with the Single Sign-On configuration within vsphere Web Client, this does not change the master password, which is used to run advanced commands and for recovery purposes when needed. TECHNICAL WHITE PAPER / 20

21 Master password The original password defined for will be used as the master password. The original password defined for will be required when changing the master password for the first time or to change the current master password again. VMware recommends that the 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 Single Sign-On, see VMware knowledge base article : Configuring and troubleshooting Single Sign-On password and lockout policies for accounts. Unlock the account using another session that is still logged in to the 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 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 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\SSO\utils. Run the following command: rsautil reset-admin-password Enter the master password when prompted. This is the password selected for the Single Sign-On administrator during installation. If it is changed later, the master password remains the one chosen originally. Enter the 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. TECHNICAL WHITE PAPER / 21

22 The message Password reset successfully should appear. To reset the Single Sign-On administrator password on the Appliance, complete the following steps: Log in as root to the 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 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 Single Sign-On instance is corrupted, it can be restored from backup to ensure continued vsphere access for and related components. To back up the Single Sign-On configuration, complete the following steps: 1. From the Windows user interface Go to Programs > VMware. Right-click Generate 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\SSO\scripts. If 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 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\ SSO\scripts\sso-backup script and change this line from: savedir=appshell.namespace(desktop).self.path to: savedir=path_to_file TECHNICAL WHITE PAPER / 22

23 Restoring the Single Sign-On Configuration To restore a 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 Single Sign-On instance. The host machine can be a physical machine or a virtual machine. It must satisfy the hardware requirements for Single Sign-On. For more information, see the Hardware Requirements for, Single Sign-On, vsphere Client, and vsphere Web Client section of the vsphere Upgrade guide. Verify that the Single Sign-On database is accessible from the host machine. Verify that you have the master password for the Single Sign-On instance that you are restoring. Verify that you have the account name and password for the RSA SSPI service and Single Sign-On service of the Single Sign-On instance that you are restoring. Download the 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 Single Sign-On server that you created the backup from. 3. If the 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 Single Sign-On host machine, in the installation directory, double-click theautorun.exe file to start the installer. 6. Select 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 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 Single Sign-On instance. NOTE: You must use the password that was created for the admin@system-domain user when 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 Single Sign-On instance that you created the backup from. 12. Follow the wizard prompts to complete the Single Sign-On restoration. If there are any 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 instances that are registered to the Single Sign-On instance, to verify that you have working access to them. TECHNICAL WHITE PAPER / 23

24 Known Issues with Workarounds Although this paper complies with the current version of release 5.1 update 1a all known issues are published with the release notes and are updated as necessary. Installation Issues Single Sign-On installation fails with error * Single Sign-On installation fails with the following error: Error 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 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. Single Sign-On installation fails with error * Single Sign-On installation fails with the following error: Error The entry is not a valid port number. The port number must be a numeric value between 1 and This issue occurs if you do not type a valid port number in the port number field during Single Sign-On installation and proceed with the installation. Workaround: Reinstall Single Sign-On. During installation, type the port number in the port number text box. Single Sign-On installation fails with error 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 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 database for with SQL 2008 R2 (VMware knowledge base article ).* On Windows 2012 or Windows 8 machines without Internet connectivity, attempts to install vsphere Client or Single Sign-On might fail with error * If Microsoft.NET Framework is not installed on Windows 2012 or Windows 8 machines, and the machines are not connected to the Internet, attempts to install vsphere Client or Single Sign-On on these machines might fail with an error message similar to the following: Internal Error Workaround: Install.NET Framework 3.5 SP1 on the machines before installing vsphere Client or Single Sign-On. TECHNICAL WHITE PAPER / 24

25 During Single Sign-On installation, a warning message is displayed. The Single Sign-On 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. Inventory Service fails to start on installation after rollback of Single Sign-On installation using Simple Install. After Single Sign-On installation rollback, if you select the new installation folder as the subfolder under the folder used for the previous installation, 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, Inventory Service fails to start. Workaround: If Single Sign-On installation rolls back using Simple Install, select the same installation folder used for the previous installation. 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 Single Sign-On: < SSOInstaller Folder >\Single Sign On\DBScripts\SSO\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. Single Sign-On server installation fails on systems running IBM DB2 9.7 Fix Pack 1 or earlier. Components of Single Sign-On require DB2 9.7 Fix Pack 2 or later. When you attempt to install 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. TECHNICAL WHITE PAPER / 25

26 Installation fails when you install Single Sign-On with a local database on a Turkish version of Windows 2008 R2 64-bit. You might get an error (Error or 20010) when you install Single Sign-On in a Turkish Windows environment and the database is on the local system. This error occurs when SQL capitalizes certain letters, which makes the database incompatible with Single Sign-On. Workaround: 1. Install the database on a separate system running an English version of Windows Run the Single Sign-On installer on the system running the Turkish version of Windows Connect to the database remotely. Installation of a Single Sign-On highavailability or recovery node fails if master password and administrator password are different. The following occurs when you install Single Sign-On in high-availability mode: - When you provide the correct Single Sign-On administrator password, validation appears to be successful, but installation fails with an error message stating that the Single Sign-On master password is incorrect. - When you provide the correct Single Sign-On master password, validation fails because the installer is expecting the Single Sign-On administrator password. The following occurs when you install Single Sign-On in recovery mode: - When you provide the correct Single Sign-On administrator password, installation fails with an error message stating that the Single Sign-On master password is incorrect. - When you install Single Sign-On on a domain machine and you provide the correct 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 Single Sign-On administrator password. - When you install Single Sign-On on a workgroup machine, installation fails with an error message stating that the Lookup Service configuration failed. The log file contains an error message stating that the Single Sign-On administrator password is incorrect. Workaround: Ensure that the same password is used for the Single Sign-On master password and the 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\ SSO. - Single Sign-On master password: <ssoserver folder>\utils>rsautil.cmd manage-secrets -a list - 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: - Single Sign-On master password: <ssoserver folder>\utils\rsautil.cmd manage-secrets -a change -m <master password> -N <new Master Password> - Single Sign-On administrator password: <ssoserver folder>\utils\rsautil.cmd reset-admin-password -m <master password> -u <admin> -p <pass> The Single Sign-On administrator password expires by default in 365 days. When you reset this password, also reset the Single Sign-On master password to ensure that they remain the same. TECHNICAL WHITE PAPER / 26