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.

  For upgrades, add the agents to the LDT Communication Group using the Add Client function on CM. See Adding Clients to an LDT Communication Group for more information.

• 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.