Sharing LDT NFS/CIFS GuardPoints between Linux and Windows
An LDT GuardPoint Group is used to organize clients guarding the same NFS or CIFS share. In CTE 7.5.0 or previous versions, each group could only contain Linux or Windows members, and not a mix of the two. Starting with CTE 7.6.0, it is now possible to have Windows clients as AccessOnly clients to guard a share that is part of a Linux LDT GuardPoint Group. Refer to Configuring CTE Windows LDT AccessOnly nodes for more information on AccessOnly clients.
Windows LDT is capable of mixing AccessOnly, and non-AccessOny clients, in an LDT GuardPoint Group group accessing a share through CIFS protocol. This capability is possible because of the CIFS protocol supporting exclusive access to a file from a remote node. Linux LDT does not support AccessOnly clients because the NFS protocol does not support exclusive file access capability. Therefore, an AccessOnly client is not privy to LDT messages between clients. The Windows client can only access a Linux based LDT GuardPoint Group while a GuardPoint is rekeyed. As such, Windows clients can only guard after the Linux primary client has completed rekey on the GuardPoint. Subsequently, the GuardPoint must be unguarded on Windows clients before any subsequent key rotation begins. Failure to do so will cause data corruption as any write operation from the Windows client may write without any coordination with the Linux primary client performing transformation.
The capability to allow Windows and Linux clients to guard the same GuardPoint is supported on GuardPoint directories which have been guarded for the first time, and completed the initial transformation, by a CTE 7.6.0 Linux client. This restriction is in place because there are metadata format changes in newly created GuardPoints to support sharing access between Linux and Windows clients.
Note
Access to shared GuardPoints is available through NFS on Linux and CIFS on Windows.
Windows clients are blocked from accessing files marked with a lazy_rekey flag. This is because the files marked with a lazy_rekey flag will launch the data transformation process the next time a Linux member of the LDT GuardPoint Group accesses the file without any awareness of Windows clients sharing access to the GuardPoint.
Although there is no communication between Windows and Linux clients for sharing access to GuardPoints, there is awareness of shared access across the clients because of the LDT metadata changes applied to the newly created GuardPoints for sharing on both platforms. Both platforms apply compatible LDT metadata when creating new files.
Finally, suspending rekey does not qualify Windows clients to guard and share access. Rekey must be completed before Windows clients can attempt to guard.
LDT Communication Group
All members of an LDT Communication Group must be Linux CTE clients. Windows clients do not belong to LDT Communication Groups because of AccessOnly mode configuration.
Limitations
• Only new GuardPoints are supported in v7.6.0.
• All existing CTE clients must be upgraded to CTE Agent v7.6.0, or a subsequent version.
• Guarding a GuardPoint for the first time on Windows disqualifies the GuardPoint for sharing between Windows and Linux, and subsequent attempts on a Linux client to guard.
• Windows AccessOnly client fails to guard the GuardPoint while rekey is suspended.
• All Windows clients must unguard before the key rotates on CipherTrust Manager.
