Use LunaCM to create an HA group from partitions assigned to your client. This procedure is completed by the Crypto Officer. Ensure that you have met all necessary prerequisites before proceeding with group creation. For a detailed description of HA functionality, see High-Availability Groups.
NOTE Your LunaCM instance needs to update the Chrystoki.conf (Linux/UNIX) or crystoki.ini file (Windows) when setting up or reconfiguring HA. Ensure that you have Administrator privileges on the client workstation.
V1 partitions: If you add an application partition with an existing SMK to an HA group, the primary member's SMK overwrites the existing SMK of the joining partition.If a partition's SMK has ever been used to encrypt important SKS objects, save a backup of the SMK before adding that partition to any HA group.
Prerequisites
HA groups are set up in LunaCM by the Crypto Officer. Before the CO can perform this setup, however, all HSMs and member partitions must meet the following prerequisites, completed by the HSM and Partition Security Officers.
HSMs
The HSM SO must ensure that all HSMs containing HA group member partitions meet the following prerequisites:
>All HSMs must use the same authentication method (password/multifactor quorum). Luna Cloud HSM Services support HA groups using password authentication only.
>HA groups cannot contain both Luna PCIe HSM 7s and Luna Network HSM 7s.
>All must be running one of the supported software/firmware versions. Generally, Thales recommends using HSMs with the same software/firmware for HA. However, mixed-version HA groups containing Luna 6 and 7 member partitions and Luna Cloud HSM services are supported. See Cloning Keys Between Luna 6, Luna 7, and Luna Cloud HSM, Password or Multifactor Quorum for more information.
>For Luna PCIe HSM 7s, all HSMs must have the same firmware version installed and must be installed in the same host server that will create the HA group.
>HSM policies 7: Allow Cloning and 16: Allow Network Replication must be set to 1
>HSM policies must be consistent across all HSMs.
NOTE For HSM policy 12: Allow non-FIPS algorithms, note the following:
>If you are using Luna HSM Client 10.4.0 or newer, you can set up an HA group with a mix of FIPS and non-FIPS partitions as members. However, some limitations must be considered. For more information, refer to Key Replication.
>If you are using Luna HSM Client 10.3.0 or older, you cannot set up an HA group with a mix of FIPS and non-FIPS partitions as members.
A client can have a session with an STC slot, making use of only one appID. When running an HA command if you are already logged in or have a session open with an appID to a member of that HA slot, you will not be able to log into that slot at this time. When you run a command like "ha list", lunacm logs into each member using a randomly created appID. If any one of these slots already has a login session, such an attempt is rejected with CKR_ACCESS_ID_ALREADY_EXISTS. The workaround is to close the problem session first.
Partitions
The Partition SO must ensure that all partitions in an HA group meet the following prerequisites:
>All partitions must be visible in LunaCM on the
>All partitions must be initialized with the same cloning domain:
•Password-authenticated partitions must share the same domain string.
•multifactor quorum-authenticated partitions must share the same red domain PED key.
>Partition policies 0: Allow private key cloning and 4: Allow secret key cloning must be set to 1 on all partitions.
>Partition policies must be consistent across all member partitions.
>The Crypto Officer role on each partition must be initialized with the same CO credential
>PED-authenticated partitions must have partition policies 22: Allow activation and 23: Allow auto-activation set to 1. All partitions must be activated and have auto-activation enabled, so that they can retain their login state after failure/recovery. Each partition must have the same activation challenge secret set (see Activation on Multifactor Quorum-Authenticated Partitions)
NOTE If HSM policy 21: Force user PIN change after set/reset is set to 1 (the default setting), the Crypto Officer must change the initial CO credential before using the partition for cryptographic operations
To set up an HA group
1.Decide which partition will serve as the primary member (see The Primary Partition). Create a new HA group, specifying the following information:
•the group label (do not call the group "HA")
• the Serial number OR the slot number of the primary member partition
•the Crypto Officer password or challenge secret for the partition
lunacm:>hagroup creategroup -label <label> {-slot <slotnum> | -serialnumber <serialnum>}
lunacm:> hagroup creategroup -label myHAgroup -slot 0
Enter the password: ********
New group with label "myHAgroup" created with group number 1154438865287.
Group configuration is:
HA Group Label: myHAgroup
HA Group Number: 1154438865287
HA Group Slot ID: Not Available
Synchronization: enabled
Group Members: 154438865287
Needs sync: no
Standby Members: <none>
Slot # Member S/N Member Label Status
====== ========== ============ ======
0 154438865287 par0 alive
Command Result : No Error
LunaCM generates a serial number for the HA group (by adding a "1" before the primary partition serial number), assigns it a virtual slot number, and automatically restarts.
lunacm (64-bit) v7.3.0. Copyright (c) 2018 SafeNet. All rights reserved.
Available HSMs:
Slot Id -> 0
Label -> par0
Serial Number -> 154438865287
Model -> LunaSA 7.3.0
Firmware Version -> 7.3.0
Configuration -> Luna User Partition With SO (PW) Key
Export With Cloning Mode
Slot Description -> Net Token Slot
Slot Id -> 1
Label -> par1
Serial Number -> 1238700701509
Model -> LunaSA 7.3.0
Firmware Version -> 7.3.0
Configuration -> Luna User Partition With SO (PW) Key
Export With Cloning Mode
Slot Description -> Net Token Slot
Slot Id -> 5
HSM Label -> myHAgroup
HSM Serial Number -> 1154438865287
HSM Model -> LunaVirtual
HSM Firmware Version -> 7.3.0
HSM Configuration -> Luna Virtual HSM (PW) Key Export With
Cloning Mode
HSM Status -> N/A - HA Group
Current Slot Id: 0
2.Add another partition to the HA group, specifying either the slot or the serial number. If the new member contains cryptographic objects, you are prompted to decide whether to replicate the objects within the HA group, or delete them.
lunacm:>hagroup addmember -group <grouplabel> {-slot <slotnum> | -serialnumber <serialnum>}
lunacm:> hagroup addmember -group myHAgroup -slot 1
Enter the password: ********
Warning: There are objects currently on the new member.
Do you wish to propagate these objects within the HA
group, or remove them?
Type 'copy' to keep and propagate the existing
objects, 'remove' to remove them before continuing,
or 'quit' to stop adding this new group member.
> copy
Member 1238700701509 successfully added to group myHAgroup. New group
configuration is:
HA Group Label: myHAgroup
HA Group Number: 1154438865287
HA Group Slot ID: 5
Synchronization: enabled
Group Members: 154438865287, 1238700701509
Needs sync: no
Standby Members: <none>
Slot # Member S/N Member Label Status
====== ========== ============ ======
0 154438865287 par0 alive
1 1238700701509 par1 alive
Please use the command "ha synchronize" when you are ready
to replicate data between all members of the HA group.
(If you have additional members to add, you may wish to wait
until you have added them before synchronizing to save time by
avoiding multiple synchronizations.)
Command Result : No Error
Repeat this step for each additional HA group member.
3.If you are adding member partitions that already have cryptographic objects stored on them, initiate a manual synchronization. You can tell whether this step is required by checking the line Needs Sync : yes/no in the HA group output. This will also confirm that the HA group is functioning correctly.
lunacm:> hagroup synchronize -group <grouplabel>
4.[Optional] If you created an HA group out of empty partitions, and you want to verify that the group is functioning correctly, see Verifying an HA Group.
5.Specify which member partitions, if any, will serve as standby members.
See Setting an HA Group Member to Standby.
6.Set up and configure auto-recovery (recommended). If you choose to use manual recovery, you will have to execute a recovery command whenever a group member fails.
See Configuring HA Auto-Recovery.
7.[Optional] Enable HA Only mode (recommended).
See Enabling/Disabling HA Only Mode.
8.[Optional] Configure HA logging.
See HA Logging for procedures and information on reading HA logs.
The HA group is now ready for your application.
