If you encounter problems with an HA group, refer to this section.
Cryptographic Operations Blocked During Remote PED Operations When Audit Logging Is Enabled
With audit logging enabled on the HSM, crypto operations are blocked on all application partitions during Remote PED operations. During this time, requests sent to HA member partitions on this HSM will not fail over to other members. When the Remote PED operation is complete, all crypto operations resume normally. If your application has its own timeout programmed, it may incorrectly conclude that the entire HA group has failed.
Using Luna HSM Client 10.7.2 or newer, you can configure the ProbeTimeout setting in the Chrystoki.conf/crystoki.ini file to trigger an HA failover after a specified time. This allows operations to continue normally during Remote PED operations.
Administration Tasks on HA Groups
Do not attempt to run administrative tasks on an HA group virtual slot (such as altering partition policies). These virtual slots are intended for cryptographic operations only. It is not possible to use an HA group to make administrative changes to all partitions in the group simultaneously; the exception is lunacm:> partition changepw using Luna HSM Client 10.7.0 or neewer.
Unique Object IDs (OUID)
If two applications using the same HA group modify the same object using different members, the object fingerprint might conflict.
Client-Side Limitations
New features or abilities, or new cryptographic mechanisms added by firmware update, or previously usable mechanisms that become restricted for security reasons, can have an impact on the working of an HA group, when the Luna HSM Clientversion is older. Luna Clients are "universal" in the sense that they are able to work fully with current Luna HSMs/partitions, and with earlier versions, as well as with cloud crypto solutions (DPoD Luna Cloud HSM service), but a client version cannot be aware of HSM versions that were not yet developed when the Client was released.
Client-Side Failures
Any failure of the client (such as operating system problems) that does not involve corruption or removal of files, should resolve itself when the client is rebooted.
If the client workstation seems to be working fine otherwise, but you have lost visibility of the HSMs in LunaCM or your client, try the following remedies:
>verify that the Thales drivers are running, and retry
>reboot the client workstation
>restore your client configuration from backup
>re-install Luna HSM Client and re-configure the HA group
For Luna PCIe HSM 7, the client is the HSM host. If HA has been working, any sudden failure is likely to be OS or driver related (restart) or file corruption (re-install). If a re-installation is necessary, you must recreate and reconfigure the HA group.
Avoid direct access to individual HA group members when securing with STC
Some security settings and implications
TIP Security Note -Cloning policies (0 and 4) permit or deny the ability to securely copy keys and objects into and out of a partition.
The Key Management Functions policy (28) controls the ability to create, delete, generate, derive, or modify cryptographic objects in the current partition.
These controls are independent of each other. With Key Management functions denied, you can still clone objects in and out of partitions where Cloning policy is allowed. Thus HA (high availability) operation can clone keys into a partition that disallows Key Management functions (creation, deletion, etc.). Cloning a key or object into a partition is not considered creation - the key or object already existed within the security / cloning domain that encompasses the partition.
Ultimately the security administrators define where keys can exist by controlling distribution of the security / cloning domain, and by defining policies around those keys.
Additionally, key owners can choose to make their keys non-modifiable and non-extractable, if those options are indicated by your use-case.
