Secondary Reports Error, "No SKID Authentication Available On The Connection" after Joining to a Secure Global Desktop Array (Doc ID 2135860.1)

Last updated on MAY 30, 2016

Applies to:

Oracle Secure Global Desktop - Version 5.2 to 5.2 [Release 5.0]
Information in this document applies to any platform.

Symptoms

In this scenario, the Secure Global Desktop (SGD) array consists of 2 or more servers and configured to use the automatic failover feature, as described in:  http://docs.oracle.com/cd/E51728_01/E51731/html/arrays.html#array-resilience

 In such an environment, this behavior may be staged after the existing array primary becomes inoperative due to a significant destructive event--such as disk corruption---initiating the Automatic failover functionality.   After this event, the original primary is  detached, repaired, and re-installed with SGD. 

This error may then arise when attempting to re-join (add) the original primary node back into the SGD array, as demonstrated below:

NOTE: In the example below, demo1.sgd.com is the original primary.

 

Once in this state for a short period of time, subsequent runs of the "tarantella status" on the fail over primary (demo2 in this example) will show that it also switches to a standalone server.  (Specifically, demo1 is no longer listed as an array member.)   Attempts to login to demo1 will present the "No SKID authentication" error.    Finally, the SGD Administrator may find that the SGD Datastore (also know as the ENS) has not been successfully replicated from the acting primary to the restored secondary (demo1).

Attempts to resolve this behavior by breaking the array, running "tarantella clean" on the original primary (demo1 in this example) and the current primary and re-attempting the join will result in the same behavior.

Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms