Overview

This section details the CipherTrust software suite and will act as an operational (run book) guide for managing the CipherTrust security environment. It contains the steps to configure CTE agent on a Windows Server host running Microsoft Distributed File System (DFS) with Replication.

Microsoft introduced the Distributed File System in Server 2003 as a value-add for customers seeking low-cost data resiliency across high-latency, low-bandwidth WAN links. DFS is a free feature included with all subsequent versions of Windows Server software. DFS uses a namespace architecture where nested data folders use a replication service to synchronize similar data directories on 2 or more servers. Architects choose this model to ensure fault tolerance, preserve active uptime and to improve access performance by spreading the workload across many servers: client requests are routed to the nearest DFS folder for a given namespace. CTE began supporting DFS(R) starting with Windows 2012 R2 and continues to do so through Windows 2022 and subsequent versions.

Use this document for guidance on encrypting DFS data depending on how it is currently deployed. It contains a number of scenarios, often highlighting important configuration considerations applicable for the project. Before encrypting any DFS data, however, Thales Support assumes that the customer has made a backup of the latest production data, has a good understanding of their own DFS(R) deployment and has a fully-developed encryption plan.

The information listed here details best practices and tool sets when using encryption for DFS data. It starts by defining the terms and layouts for this technology and ends by reviewing common problems that may compound DFS(R) encryption and troubleshooting tips.

CTE Encryption Methods

CTE supports two encryption methods:

• Standard offline data transformation

  Where the data is unavailable while it is being encrypted or rekeyed.

• Live Data Transformation

  Where the data is encrypted and rekeyed in the background while it remains accessible to users. This method requires a separate license for the LDT feature.

While DFS(R) policies have some unique required components, the basic policy and GuardPoint creation process is identical to non-DFS(R) environments. For details about offline data transformation, see the CTE Data Transformation Guide. For details about LDT, see the CTE Live Data Transformation with CipherTrust Manager.

Considerations with DFS(R)

If you are using CTE in a DFS(R) environment, keep in mind the following:

• You should always back up your data prior to beginning the encryption process and you should have a full backup of the data in the hub server before you restore a spoke.

• You cannot place a GuardPoint anywhere on the boot drive, so if your DFS(R) replication point is currently C:\, or a directory under C:\ such as C:\data\, you need to move that data and its replication point to a new volume on the server before you can encrypt it.

• If you are backing up your DFS data, make sure that your backup software is not backing up the archive bit. File replication is triggered by file version change or a modified time stamp. As such, there is a chance that updating the archive bit may cause issues that trigger a replication storm, which will then put a heavy encryption load on the servers.

• You must add the CTE GuardPoint at or above the level of the DFS(R) replication point. For example:

  • If the replication point is D:\, the CTE GuardPoint must also be at D:\. Adding a GuardPoint on a directory in D:\, such as D:\data\, will fail.

  • If the replication point is D:\data\, you can add a GuardPoint at D:\data\ or D:\, but you cannot add a GuardPoint on a subdirectory of D:\data\ such as D:\data\HR-files\.

• When you set a replication point, Microsoft automatically creates a private directory called <dir name>\DfsrPrivate that resides with that replication point. For example, if the replication point is set on D:\, the private directory would be D:\DfsrPrivate. If the replication point is set on D:\data\, the private directory would be D:\data\DfsrPrivate.

  How this private directory must be handled depends on the the encryption method that you are using.

  • For Standard encryption, you must guard the private directory with the same policy that you use for the main GuardPoint. If the GuardPoint is at the root of the volume (for example, D:\), this happens automatically. But if you are guarding a specific directory, such as D:\data\, you need to create a second GuardPoint using the same policy on D:\data\DfsrPrivate.

  • For LDT, you must guard the private directory with the same policy that you use for the main GuardPoint, even if the GuardPoint is at the root level. (For example, you must have a GuardPoint for both D:\ and D:\DfsrPrivate\.) In addition, you must exclude this directory from LDT processing.

• The policy you specify for a DFS(R) GuardPoint cannot contain a resource set in any of the key rules included in the policy. All files in the guarded directory, and its subdirectories, must be encrypted with the same encryption key without exception. Additionally, if you rekey the GuardPoint, all files must be rekeyed with the same encryption key.

• If you want to change from one encryption key to an entirely different encryption key (as opposed to rekeying the data with a new version of the existing key), you must decrypt the data and remove all existing GuardPoints so that you have a clean environment. Then you can start the CTE encryption process over from the beginning.

  You cannot change from one encryption key to another if any of the existing data is still encrypted with the old key. If you attempt to do so, you may encounter data replication errors and you may need to delete the entire volume and recreate it.

• When CTE encrypts data on a node, the encrypted data must be replicated to other nodes in the configuration. This may result in increased replication activity on the network.