Onboarding with the KSS
There are three options when onboarding end users with the KSS:
The KSS ID is included in the enterprise configuration file before the end user first launches Atakama.
The KSS ID is added to the end user’s local atakama.config before the end user first launches Atakama.
The end users initiate onboarding via the CLI using the command:
atakama profile keyserver-onboard --keyserver-id [ID]
With any of these options, onboarding the end user is automatic and without end-user involvement. Once onboarded, the end user will have received:
An Atakama Profile with the default name, username@hostname, containing two devices -- the workstation and the KSS.
A personal Security Group.
Two default Secure Folders (disabled for non-administrator end users).
The end user may be prompted to configure additional Secure Folders after the onboarding depending on the enterprise configuration.
Sharing
Sharing within the KSS environment is similar to sharing when Atakama is deployed without a KSS. User profiles with access to the Secure Folder locations must still be verified and then granted access by the administrator. The KSS does not support granting access to other profiles, so each Secure Folder must contain at least one additional non-KSS profile.
Additional Commands
Enabling/Disabling the Key Shard Server
All request responses can be disabled via the command
atakama keyserver disable
When the KSS is disabled, you must use the command to re-enable it
atakama keyserver enableTo see the status of the KSS and to retrieve its ID, use the command
atakama keyserver statusThese commands work for both a regular Key shard server or keyshard Server instances in Cluster Mode.