Page Comparison

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

This page specifies the steps for updating a clustered deployment of a Ubisecure SSO configuration where at least one of the SSO nodes is operational during the whole procedure. The scope of the document includes the update steps of the SSO nodes and the LDAPs. Update of the reverse proxy server is not included in this document.

SSO Cluster

The diagram below describes an SSO cluster configuration to be updated.

High availability is achieved by using two SSO instances so that there is one active SSO node, and another, passive, as high availability option if another SSO node is not available. A reverse proxy is used to switch the traffic in case of failures. In case of high-performance setup, the traffic load can be distributed between both SSO nodes by the reverse proxy.

Note that LDAP content is replicated between the SSO instances, but both SSO nodes use their own LDAP (LDAPs can be installed also on their own nodes).

A reverse proxy is configured to use primarily SSO 1 node, and SSO 2 node only when SSO 1 node is not available. During the update operation, the reverse proxy is used to switch traffic away from an SSO node that is being updated while the other SSO node is still operational.

Image Removed

Clustered SSO Update

Update Procedure Overview

An overview of updating an Ubisecure SSO cluster is described in the following steps:

...

1. Use the Active Directory Schema snap-in to connect an AD LDS instance
2. Identify the schema master

...

Overview

This page specifies the steps for updating a clustered deployment of a Ubisecure SSO configuration where at least one of the SSO nodes is operational during the whole procedure. The scope of the document includes the update steps of the SSO nodes and the LDAPs. Update of the reverse proxy server is not included in this document.

SSO Cluster

The diagram below describes an SSO cluster configuration to be updated.

High availability is achieved by using two SSO instances so that there is one active SSO node, and another, passive, as high availability option if another SSO node is not available. A reverse proxy is used to switch the traffic in case of failures. In case of high-performance setup, the traffic load can be distributed between both SSO nodes by the reverse proxy.

Note that LDAP content is replicated between the SSO instances, but both SSO nodes use their own LDAP (LDAPs can be installed also on their own nodes).

A reverse proxy is configured to use primarily SSO 1 node, and SSO 2 node only when SSO 1 node is not available. During the update operation, the reverse proxy is used to switch traffic away from an SSO node that is being updated while the other SSO node is still operational.

Image Added

Clustered SSO Update

Update Procedure Overview

An overview of updating an Ubisecure SSO cluster is described in the following steps:

1. Find out which SSO node is the schema master
   1. Use the Active Directory Schema snap-in to connect an AD LDS instance
   2. Identify the schema master
2. Configure the reverse proxy server to route the production traffic only to the SSO 2 node
   1. Setup both SSO nodes for the activity test
   2. Optional: Test through the reverse proxy server which SSO node is active
   3. Disable traffic from the reverse proxy server to the SSO 1 node
   4. Test through the reverse proxy server which SSO node is active
3. Disable the replication
   1. Stop the Ubiloginserver process from the SSO 1 node
   2. Disable outbound and inbound replication from the SSO 2 node
   3. Disable outbound and inbound replication from the SSO 1 node
4. Configure the metadata clean up for the retired AD LDS instances in the SSO 1 node
   1. Clean up the metadata from the SSO 1 node using the dsmgmt tool
   2. Remove the SSO 2 node server object from the SSO 1 node using the ADSI Edit tool 
5. Update the SSO 1 node
   1. Use document: Upgrade on Windows - SSO
   2. Test the functionality of the updated SSO 1 node
6. Configure Proxy to route production traffic only to SSO 1 Server
   1. Route the traffic towards the SSO 1 node
   2. Optional: Export session information from the SSO 2 node's directory and import to SSO 1 node's directory
   3. Setup SSO 1 node for the activity test
   4. Test through the reverse proxy server which SSO node is active
7. Remove the services and the AD LDS from the SSO 2 node
   1. Stop the Ubilogin services
   2. Remove For the version to be removed, check Java 8
   3. Stop SSO and Accounting Service Windows services
   4. Remove SSO and Accounting Service Windows service configurations
   5. Remove the AD LDS from the SSO 2 node
8. Enable the replication in the SSO 1 node
9. Update the SSO 2 node
   1. Install Java 11 to the SSO 2 node
   2. Execute the steps in the document  AD LDS clustering setup (node 2) - SSO
   3. Install the new SSO version to the SSO 2 node
   4. Update Tomcat configuration by reinstalling it to the SSO 2 node
   5. See also Single node installation finalization
   6. Test the functionality of the updated SSO 2 node
10. Enable traffic from the Reverse Proxy to route production traffic to SSO 2 node in addition to the SSO 1 node

...

...

      b.   Identify the schema master

...

...

Step 7. Remove the services and AD LDS from the SSO 2 node

      a.   Stop the Ubilogin servicesFor the version to be removed, make sure you still have Java 8 installed and JRE_HOME and JAVA_HOME set

      b. Stop SSO and Accounting Service Windows services

net stop ubiloginserver

net stop ubilogindirectory

     c. Remove SSO and Accounting Service Windows service configurations

cd "C:\Program Files\Ubisecure\ubilogin-sso\ubilogin"
config\tomcat\remove.cmd

      bd.  Remove the AD LDS from the SSO 2 node

...

Step 9. Update the SSO 2 node

      a. Install Java to the SSO 2 node. You can skip this step if Java is already installed.

    Java must be preinstalled on the server (including Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files).

• Review the System Recommendations and Supported Platforms page to get information about which Java 8 version we currently support. Download one of the supported versions and follow their installation documentation.
• If you want to use a newer Java version check with our support if we have already tested Ubisecure SSO with it.

• Set up a system wide environment variables for Java
  • Modify the paths according to your Java installation.

...

Remove Java 8, install Java 11, and set JAVA_HOME according to Installation requirements - SSO.    

      b. Execute the steps in the document AD LDS clustering setup (node 2) - SSO

      c. Install the new SSO version to the SSO 2 node.

         Copy the Ubisecure SSO configurations from the SSO 1 node to the SSO 2 node.

• • In practice, this means that the SSO installation folder (C:\Program Files\

...

Environment variables can be set Control Panel → System and Security → System → Advanced system settings → Environment Variables → System Variables → New...

Image Removed

      b. Execute the steps in the document AD LDS clustering setup (node 2) - SSO

      c. Install the new SSO version to the SSO 2 node.

         Copy the Ubisecure SSO configurations from the SSO 1 node to the SSO 2 node.

• • In practice, this means that the SSO installation folder (C:\Program Files\ubisecure\ubilogin-sso) is copied as such
  • Check the win32.config file's parameter ldap.url to see if the LDAP has been installed in the localhost. If the directory (LDAP) connection is something else than "localhost" (LDAPs are installed on their own separate nodes) then modify the C:\Program Files\ubisecure\ubilogin-sso\ubilogin\config\settings.cmd file's LDAP URL parameters on the SSO node 2. 
• 1. 1. set LDAP_URL=ldap://<IP address of the LDAP server 2>:389
     2. set LDAP_URL_HOSTNAME=<IP address of the LDAP server 2>
     3. set LDAP_URL_PORT=389

      d. Update Tomcat configuration by reinstalling it (DON’T RUN setup.cmd on SSO node 2):

...

...

• • ubisecure\ubilogin-sso) is copied as such
  • Check the win32.config file's parameter ldap.url to see if the LDAP has been installed in the localhost. If the directory (LDAP) connection is something else than "localhost" (LDAPs are installed on their own separate nodes) then modify the C:\Program Files\ubisecure\ubilogin-sso\ubilogin\config\settings.cmd file's LDAP URL parameters on the SSO node 2. 
  1. 1. set LDAP_URL=ldap://<IP address of the LDAP server 2>:389
     2. set LDAP_URL_HOSTNAME=<IP address of the LDAP server 2>
     3. set LDAP_URL_PORT=389

      d. Update Tomcat configuration by reinstalling it (DON’T RUN setup.cmd on SSO node 2):

C:\Program Files\Ubisecure\ubilogin-sso\ubilogin>config\tomcat\install.cmd
Keystore already exist in c:\Program Files\Ubisecure\ubilogin-sso\ubilogin\custom\tomcat\keystore.pfx
5 File(s) copied
776 File(s) copied
[SC] ChangeServiceConfig SUCCESS
[SC] ChangeServiceConfig2 SUCCESS
[SC] ChangeServiceConfig SUCCESS
The UbiloginServer service is starting..
The UbiloginServer service was started successfully.


Ubilogin Server started at https://www.example.com/ubilogin/

      e.  . See also Single node installation finalization. For the new Java installation you must import SSO certificate to Java trust store.

      f. Test the functionality of the updated SSO 2 node. This might require separate reverse proxy server configuration. This should be planned considering the customer's application and network setup.

...