Configuring VMware vCenter Single Sign On for High Availability
search cancel

Configuring VMware vCenter Single Sign On for High Availability

book

Article ID: 322222

calendar_today

Updated On:

Products

VMware vCenter Server VMware vSphere ESXi

Issue/Introduction

Configure VMware vCenter Single Sign On for High Availability (HA) by installing two nodes in HA mode and putting them behind load balancing software. In HA mode, both the nodes work with the same database, use the same data, and have the same user stores.

When configured for High Availability, Single Sign On (SSO) cannot perform authentication with Windows users because it cannot leverage the local operating system users as user stores.


Environment

VMware vCenter Server 5.1.x
VMware vSphere ESXi 5.1

Resolution

Important: Follow this process before installing any other services, such as the Inventory service, vCenter Server, or vSphere Web Client. Single Sign On (SSO) for High Availability (HA) must be configured first.

To set up SSO for HA:

Step 1 – Prepare the Systems

  1. Create two virtual machines running a Windows guest operating system. These will be the nodes configured for SSO.
  2. Create a DNS entry for each virtual machine.
  3. (Optional) If you use Active Directory and want it to be discovered automatically by SSO:
     
    1. Put both virtual machines in the same Active Directory domain.
    2. Assign administrative permissions on both machines to the Active Directory domain user running the installation.

Step 2 – Configure SSO on the Primary Node

Install vCenter SSO on the machine that will become the Primary node. When prompted, select these options:
  • Deployment type: Create Primary node for a new vCenter Single Sign On installation.
  • Node type: Create the primary node for a new vCenter Single Sign On installation.

Step 3 – Update the ssolscli.jar file for releases earlier than vCenter Server 5.1 Update 1

Only for releases earlier than vCenter Server 5.1 Update 1, a SSO.jar file needs to be replaced on the Primary Node, for the HA functionality to be set up.
In C:\Program Files\VMware\Infrastructure\SSOServer\ssolscli, replace ssolscli.jar with the ssolscli.jar.gz file attached to this article.

Note: The ssolscli.jar.gz will need to be unzipped.
 

Step 4 – Configure SSO on the Backup Node

Install vCenter SSO on the machine that will become the backup node. When prompted, select these options:

  • Deployment type: Join an existing vCenter Single Sign On installation.
  • Node type: High availability.
  • Enter the host FQDN, port, and the password for admin@System-Domain for the primary node installed in Step 2.

    Note: The default port is 7444.

Step 5 – Define the Session Configuration on Each Single Sign On Node

On each SSO node, modify the session configuration.

  1. In a text editor, open SingleSignOn_install_dir\conf\server.xml.
  2. Locate the line:

    <Engine defaultHost="localhost" name="Catalina">
     
  3. Change it to:

    <Engine defaultHost="localhost" name="Catalina" jvmRoute="routeID">

    If you are installing Apache HTTPD as your load balancing software, for each SSO node, the value specified for the routeID must be the same as the one that is specified in the corresponding BalancerMember directive in the configuration file.
    Otherwise, for the first node, enter node1. For the second node, enter node2.
     
  4. Restart vCenter Single Sign On service.

Step 6 - Configure Load Balancing

The Load Balancer acts as a failover server. Configure the load balancing software of your choice. Because sensitive information is sent to and from SSO, the load balancing software should be configured for SSL. The requirements for load balancing software configuration include:

  • Node affinity for the machine on which the primary node is installed.
  • Entries for these SSO services:
     
    • Groupcheck: map /groupcheck to /sso-adminserver to both SSO HA nodes.
    • LookupService: map /lookupservice to both SSO HA nodes.
    • Security Token Service: map /ims to both SSO HA nodes.
    • Admin server: map /sso-adminserver to /sso-adminserver on the primary node only.

Notes:

  • Because Groupcheck is present on both of the nodes but Admin server is only present on the primary node, do not use the same path for Groupcheck and Admin server.
  • One recommended option for Load Balancing software is the Apache server with the mod_proxy and mod_proxy_balancer modules. For more information about the recommended configuration when using Apache as a load balancing software for Single Sign On, see Setting up Apache load balancing software with vCenter Single Sign On (2034157).

Step 7 – Update the Lookup Service Records

  1. Copy the root certificate of the certificate chain that issued the SSL certificate for the load balancing software to the machine on which SSO node1 is installed. For the example files in sub Step 4, copy it to C:\UpdateInfo\.
  2. From a terminal window, on each of the systems where Single Sign On is installed:
     
    1. Set the JAVA_HOME variable. Using the default location in which VMware products install JRE, run:

      set JAVA_HOME=C:\Program Files\VMware\Infrastructure\jre
       
    2. Make sure connections to the load balancing software are possible. Check your firewall settings.
    3. List the services. For example:

      Switch to the directory of SSO was installed:

      cd /d C:\Program Files\VMware\Infrastructure\SSOServer\ssolscli

      Run this command:

      ssolscli listServices https://primary_node_hostname:7444/lookupservice/sdk
       
  3. Locate the Group Check, SSO Admin, and Security Token Service (STS) services. Use Type to identify these services:
     
    • Group Check type: urn:sso:groupcheck
    • Single Sign On Admin type: urn:sso:admin
    • Security Token Service type: urn:sso:sts
       
  4. Use a text editor to create three properties files, one for each of the three services. Name the files sts.properties, gc.properties, and admin.properties. The location in which you store these files is not important. For this example, save these files to C:\UpdateInfo. Reference the output of the listServices command in Step 7-2.

    Example: The contents of the sts.properties file might look similar to:

    [service]
    friendlyName=STS for Single Sign On
    version=1.0
    ownerId=
    type=urn:sso:sts
    description=The Security Token Service of the Single Sign On server

    [endpoint0]
    uri=https://location_of_your_load_balancer:<configured port>
    /ims/STSService?wsdl
    ssl=C:\UpdateInfo\cacert.pem
    protocol=wsTrust


    Example: The contents of the admin.properties file might look similar to:

    [service]
    friendlyName=The administrative interface of the SSO server
    version=1.0
    ownerId=
    type=urn:sso:admin
    description=The Security Token Service of the Single Sign On server

    [endpoint0]
    uri=https://location_of_your_load_balancer:
    <configured port>/sso-adminserver/sdk
    ssl=C:\UpdateInfo\cacert.pem
    protocol=vmomi



    Example: The contents of the gc.properties file might look similar to:

    [service]
    friendlyName=The group check interface of the SSO server
    version=1.0
    ownerId=
    type=urn:sso:groupcheck
    description=The group check interface of the SSO server

    [endpoint0]
    uri=https://location_of_your_load_balancer:
    <configured port>/groupcheck/sdk
    ssl=C:\UpdateInfo\cacert.pem
    protocol=vmomi



    Note: On the uri line above, verify the directory groupcheck, with what is listed for Group Check Type in step 3 above. It may be /lookupservice/sdk or sso-adminserver/sdk
     
  5. Locate the serviceId for each of the three services. The service ID is located in serviceId on the list of services you created earlier.
     
  6. Open a text editor and create a separate service ID file for each of the three services. For this example, create three files (sts_id, gc_id, admin_id) and save them to C:\UpdateInfo. The service ID file (sts_id) contains only the service ID. The file must not contain any other data.

    Example:

    This is an example of the contents of the admin_id file:

    {D46D4BFD-CC5B-4AE7-87DC-5CD63A97B194}:1

    This is an example of the contents of the sts_id file:

    {D46D4BFD-CC5B-4AE7-87DC-5CD63A97B194}:2

    This is an example of the contents of the gc_id file:

    {D46D4BFD-CC5B-4AE7-87DC-5CD63A97B194}:3
     
For each of the three services, run this command:
 

<SingleSignOn install dir>\ssolscli\ssolscli updateService-d Lookup_Service_URL -u sso_administrator -p sso_administrator password -si serviceid_file -ipservice.properties

The commands must be run in this order:

 

    • sts.properties
    • admin.properties
    • gc.properties

 

 

Example:

ssolscli.cmd updateService -d https://sso1.example.com/lookupservice/sdk -u admin@System-Domain -p VMware123 -si sts_id -ip sts.properties

ssolscli.cmd updateService -d https://sso1.example.com/lookupservice/sdk -u admin@System-Domain -p VMware123 -si admin_id -ip admin.properties

ssolscli.cmd updateService -d https://sso1.example.com/lookupservice/sdk -u admin@System-Domain -p VMware123 -si gc_id -ip gc.properties

 

You have now completed the Single Sign On configuration for High Availability.

 

During the installation of vCenter Server, vSphere Web Client, and the Inventory service, you must provide the address of the new load balanced hostname for Lookup Service. The address must be in the form https://<load balancer fqdn>:<configured<font face="Times New Roman">. port>/<configured path>.

Additional Information

For translated versions of this article, see:

Attachments

ssolscli.jar.gz get_app