CTE Windows Deployment for LDT AccessOnly nodes

Currently, Windows clients that attempt to access CIFS paths must be part of an LDT Communication Group. The LDT Communication Group assigns the role of primary node to one of the clients, which performs LDT rekeying of data. All of the other clients are assigned as secondary nodes, and they do not participate in rekeying data.

There are use cases that restrict users from adding all of the nodes accessing a GuardPoint to the same LDT Communication Group, such as:

• All of the nodes accessing the GuardPoint are not able to communicate to other servers in the LDT Communication Group due to differences in security policies.

• Certain nodes, which go through frequent network disconnects, are not recommended for participation in data transformation using LDT. For example, windows endpoint protection clients or laptop users.

To overcome these limitations, CipherTrust Transparent Encryption has a new feature where systems will not be allowed to become part of an LDT Communication Group or participate in data transformation, but they will continue to access a protected LDT CIFS GuardPoint.

The new role, LDT AccessOnly, can be assigned to any CipherTrust Transparent Encryption Windows client and this client will not be added into an LDT Communication Group and will not participate in LDT data transformation or rekey.

An AccessOnly node can set a GuardPoint, however, that system will not be the system to rekey the GuardPoint.

When an LDT rekey is in-progress, AccessOnly nodes cannot access the files currently being rekeyed.

All CTE agents in an LDT Communication Group that contains CTE agents with AccessOnly nodes, must have CTE v7.4.0 or subsequent versions, installed. If you have agents with versions previous to CTE v7.4.0 in that LDT Communication Group, those agents must be upgraded.

LDT will operate in either of two modes for rekeying the data in the CIFS GuardPoint paths:

• Hybrid mode: LDT will operate in hybrid mode when a node with the LDT AccessOnly role is guarded with a CIFS path. In this mode, a primary node will open a file exclusively for LDT operations. If any node designated as a LDT AccessOnly or Secondary node tries to access the same file, then that node will be denied access to that file. After access is denied, LDT will wait for a short while and then try to obtain access again.

If the LDT process fails to open a file exclusively, it will skip the file and retry on the next pass of LDT.

• Full mode: LDT will operate in full mode when all of the nodes in the LDT Communication Group are designated as only primary or secondary nodes.

Thales recommends that you use QoS and configure the schedule so that LDT is running in the background, during off hours, to avoid any contentions.

All LDT nodes in the LDT Communication Group, and all of the AccessOnly nodes, must all have CipherTrust Transparent Encryption v7.4.0 or a subsequent version. LDT AccessOnly nodes is not a backwards compatible feature.

Setup and Configure on CipherTrust Transparent Encryption

• During Agent registration, a new option to check for AccessOnly (No LDT Transformation) displays. If user enables it, then the option to specify an LDT Communication Group name is disabled.

Setup and Configure on CipherTrust Manager

• Each client will have a client-specific option to check that enables AccessOnly (No LDT Transformation). Once checked, that client cannot be added to an LDT Communication Group.

Backup/Restore from Access-Only nodes when LDT is in progress

• While LDT is in progress, backup/restore from access-only nodes is not recommended. Backup/Restore must be performed from Primary or Secondary nodes in the LDT Communication Group. This is because while LDT is in progress, files under rekey may not be accessible from access-only nodes. This may cause the Backup/Restore process to fail as file access is denied.