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.
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:
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.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms