LDT Communication Groups and LDT GuardPoint Groups

The LDT Communication Group provides the services for management and monitoring of the members of LDT GuardPoint Groups, and supports the LDT Messaging Services. An LDT Communication Group contains a collection of LDT-enabled CTE clients that are all on the same network, managed by one CipherTrust Manager and can communicate with each other over that network. An LDT GuardPoint group consists of CTE clients guarding a common NFS/CIFS share. An LDT Communication Group enables the primary host of an LDT GuardPoint Group to communicate with the secondary hosts that are members of that GuardPoint group.

LDT Communication Group

An LDT Communication Group is mandatory when using LDT over NFS/CIFS across all CTE clients managed through CipherTrust Manager. CipherTrust Manager pushes the LDT Communication Group details to all of the CTE clients in a group.

The first CTE client added to the group is initially designated as the master node. The remaining CTE clients are replicas. All active communications go through the master node.

All CTE clients intending to guard NFS/CIFS shares with an LDT policy must be able to communicate with each other. In order for the CTE clients to communicate, they must be on the same network and in a single LDT Communication Group. The agents can specify the LDT Communication Group to join at the time of registration.

LDT Communication Group Limitations

1. You must create an LDT Communication Group on your CipherTrust Manager and manually add all of the CTE clients to it.

2. Minimum of three CTE clients required for membership to the LDT Communication Group for proper and continuous operations of LDT services across all LDT GuardPoint Groups.

3. The majority of the CTE clients must be fully operational for proper LDT operations across all LDT GuardPoint Groups.

   The LDT Communication Group requires that the majority of CTE clients are active, in order for the LDT Communication Group to work properly. If 50% of the LDT Communication Group servers, or 2 out of 3 triad nodes fail, then the LDT Communication Group cannot recover from that situation. To fix this issue, you must either:

   • Reboot all of the CTE clients in the entire LDT Communication Group.

   • In Windows, restart secfsd through the Control Panel > Services page on all of the CTE clients in the entire LDT Communication Group.

4. The name of the LDT Communication Group cannot contain special characters.

5. If you are repurposing a CTE client that is currently being used for LDT over NFS/CIFS, but still runs CTE and is still registered to the same CM, then you must:

   1. Remove all CIFS/NFS LDT GuardPoints from the host prior to removing the host from the LDT Communication Group.
   2. Reboot the host.

6. Remove a host from the LDT Communication Group if the host is being decommissioned, meaning that you plan to power it down for the foreseeable future, or while CTE is being uninstalled.

LDT Communication Group Considerations

• The LDT Communication Group must be specified at the time of client registration.

• Do not shut down the entire LDT Communication Group at once. This is so that maintenance cycles can activate and run. Perform maintenance in a round robin fashion.

• Remove a host from the LDT Communication Group if the host is being decommissioned, meaning that you plan to power it down for the foreseeable future, or while CTE is being uninstalled.

• The CTE host that is the LDT Communication Group master is critical for proper operations of LDT across all LDT GuardPoint Groups. Thales recommends that you dedicate a separate host as your LDT Communication Group master, although it is not mandatory. This isolates the host from unexpected system failures, hence preventing failover of the LDT Communication service to another CTE client critical for your production workload.

• Thales recommends using a minimum of three nodes for optimal performance.

To create and manage LDT Communication Group in the UI, see: Managing LDT Communication Groups.

Multiple LDT Communication Groups Considerations

CipherTrust Transparent Encryption now supports multiple LDT Communication Groups. Be careful to not misconfigure the multiple LDT Communication Groups:

• You cannot use identical NFS/CIFS share paths in multiple LDT Communication Groups registered to a single CipherTrust Manager. Each share path must be unique.

• You cannot use identical NFS/CIFS share paths in an LDT Communication Group with the same name on multiple CipherTrust Managers. LDT Communication Group names must be unique.

Moving Client Nodes from one LDT Communication Group to another LDT Communication Group

If you are repurposing a CTE client node that is currently used for LDT over NFS/CIFS in an LDT Communication Group, but still runs CipherTrust Transparent Encryption and is still registered to the same CipherTrust Manager, then you must remove all CIFS/NFS LDT GuardPoints from the host prior to removing the host from the LDT Communication Group. Then you can reboot the host and add that CTE client node to another LDT Communication Group.

LDT GuardPoint Group

As described, an LDT GuardPoint Group is a group of three or more CTE hosts sharing access to the same GuardPoint over NFS/CIFS. A CTE host with n number of GuardPoints has membership to n number of distinct GuardPoint Groups and is specific to the GuardPoint directory. A CTE host guarding multiple GuardPoints over NFS/CIFS is a member of multiple LDT GuardPoint Groups.

LDT GuardPoint Group Primary

One CTE host in each LDT GuardPoint Group assumes the Primary role for that group. The CTE host that enables a GuardPoint directory first is assigned the primary role for the group associated with the GuardPoint directory. Subsequent hosts enabling the same GuardPoint are assigned Member or Secondary status. A CTE host can be a primary for a group, or multiple groups, and a secondary for other groups.

LDT manages primary host departure from the group during transformation. Departure of a primary host can occur as the result of disabling a GuardPoint directory on the primary host, or an unexpected failure of a primary host. In the event of the primary host departure from the group, LDT elects and delegates the primary role to one of the members of the group. Refer to Failover for additional information.

LDT GuardPoint Group Capability Level

In CTE 7.6.0, LDT NFS introduces a feature called: Capability Level, which is for an LDT Communication Group. The feature is based on the compatibility level for each member in the group. The Capability Level of a member determines what features that host can access and use, and allows the group to decide on a common capability level at which to run. This allows support for multiple versions of CTE in the same LDT Communication Group as the group runs at the capability level of the least capable member. The capability level of the group is calculated when a member leaves the group, or a primary failover occurs. As lesser capable members depart the group, the overall capability level of the group increases. The capability level of a group cannot be decreased. As such, members at a lesser capability level cannot join once the capability level of the group has increased. New members joining an existing group will attempt to join with the highest capability level supported by the host and, if rejected, retry with progressively lower capability levels until the group accepts the join request. If the group is running at a capability level that exceeds the joining member’s highest capability, that host is not allowed to join the group.

When a new feature is introduced that is unavailable to, or incompatible with, older versions of CTE agents, the maximum capability level of the newer agents is increased to a value greater than the maximum capability level of the older agents. If there is a group with a mix of the new and old agents, the group runs at the capability level of the older agent. This means that no member of the group will be allowed to use the new feature, regardless of the actual version of CTE running on the member. Only after all of the members running the older agent have left the group will the group be upgraded to the new capability level and use of the new feature is enabled. Older agents will no longer be allowed to join the group as there are now features in use that are not available to, or compatible with, older agents. If the LDT GuardPoint Group needs to contain the older agent, then a member running that older agent must be present at all times to ensure that the compatibility level of the group is not upgraded to the level of the newer agents.

To find the capability level of an LDT GuardPoint Group, type:

    voradmin ldt group capability <GuardPoint Path>

This command outputs the capability level that the current host is running at for the specified GuardPoint. If the host is the primary host, then the value also represents the capability level for the entire group.