Your suggested change has been received. Thank you.

close

Suggest A Change

https://thales.na.market.dpondemand.io/docs/dpod/services/kmo….

Thales Logo

All

  • All
back

Managing Clients

Client Settings

search

Please Note:

Client Settings

Applications such as su, sshd, and login authenticate users' identity by requesting user credentials (user name and password). These are signed applications that identify and authenticate before a child process is executed.

GuardPoints can have an associated policy that restricts access to the data stored in them. For a process to access the data, the user's associated identity must be authorized. This authorization can be done by adding an entry to the Settings field on the Client Settings tab. This entry specifies a program, such as mentioned above, with a keyword that indicates the type of authorization that is applied.

Client settings configured on the CipherTrust Manager are pushed to the clients periodically.

Any changes to the client settings are not automatically signed. Signatures of the newly added processes are compared against the signatures in the existing settings. If they differ, an error message is generated. Refer to Re-Sign Settings for steps to configure this setting. Refer to the CTE Agent Advanced Configuration and Integration Guide specific to your platform for details about this feature.

Client settings can also be configured at the client group level, refer to Inheritance of Client Group Settings for details.

Note

Refer to CTE Linux Authentication and Client Settings for detailed and additional information on authentication and client settings.

Client Settings for Linux

Specify the authentication mechanisms in place for certain binaries on the client machine.

Default Settings for Linux

|authenticator|/usr/sbin/sshd
|authenticator|/usr/sbin/in.rlogind
|authenticator|/bin/login
|authenticator|/usr/bin/gdm-binary
|authenticator|/usr/bin/kdm
|authenticator_euid|/usr/sbin/vsftpd

Add, edit, or modify authentication settings as appropriate.

Additional Settings for HDFS (Linux Clients)

Depending on the Hadoop security authentication mode, additional settings are needed for CTE clients in an HDFS cluster. Add the following settings as appropriate.

/usr/jdk64/jdk1.8.0_40/bin/java is the Java executable used to launch the HDFS services. Change the

Note

Java jdk path to reflect your end-user environment.

  • Sample setup when hadoop.security.authentication mode is simple.

    |authenticator+arg=+class=org.apache.hadoop.hdfs.server.namenode.NameNode|/usr/jdk64/jdk1.8.0_40/bin/java
|authenticator+arg=+class=org.apache.hadoop.hdfs.server.datanode.DataNode|/usr/jdk64/jdk1.8.0_40/bin/java

  • Sample setup when hadoop.security.authentication mode is Kerberos.

    |authenticator+arg=+class=org.apache.hadoop.hdfs.server.namenode.NameNode|/usr/jdk64/jdk1.8.0_40/bin/java
|authenticator+arg=+class=org.apache.hadoop.hdfs.server.datanode.SecureDataNodeStarter|/usr/lib/bigtop-utils/jsvc

Specify Authentication Settings

To specify authentication settings for the client:

  1. Open the Transparent Encryption application.

  2. Under Client Name, click the desired client.

  3. Click the Client Settings tab. The Settings text box contains the authentication settings.

    Each line has the format:

    |privilege|/path/to/binary

    Refer to Client Settings Keywords for keywords.

  4. In the Settings box, specify the authentication mechanism.

    Note

    • To delete the settings, delete the content and click Apply.
    • To edit the settings, modify the content and click Apply. When editing the setting strings, follow the format |privilege|binary.
    • To cancel any changes, click Cancel.

  5. Click Apply.

Client Settings for Windows

For applications running under WOW64 that require some form of user authentication, create entries on the Client Settings tab. The syswow64 paths are created by default when the CTE Agent is installed. \Windows is for Windows XP and Windows Itanium operating systems.

In WOW64, all file access to C:\Windows\System32 is redirected to C:\Windows\syswow64, and is implemented using the File System. Redirected syswow64 paths are effective only for 64-bit Windows file agents. This is the path where programs compiled for 32-bits are stored to run on a 64-bit system.

Before proceeding, verify that the volume letter and the path for the Windows system are correct. When the CTE Agent is installed, the volume letter defaults to C: It is possible that the executables on the Client Settings tab are on a different volume or in a different folder. If the volume or path information is incorrect, the CipherTrust Manager cannot sign the applications, and it cannot apply Agent Lock and System Lock.

Default Settings for Windows

||C:\WINDOWS\system32\winlogon.exe
|lock|C:\WINDOWS\system32\msiexec.exe
|lock|C:\WINDOWS\system32\wuauclt.exe
|lock|C:\WINDOWS\system32\wupdmgr.exe
|lock|C:\Program Files\Vormetric\DataSecurityExpert\Agent\Secfs\sec\bin\vminstall.exe
|exempt|C:\WINDOWS\explorer.exe
|exempt|C:\WINDOWS\regedit.exe
|exempt|C:\WINDOWS\system32\regedt32.exe
|exempt|C:\WINDOWS\system32\svchost.exe
|exempt|C:\WINDOWS\system32\services.exe
|exempt|C:\WINDOWS\system32\smss.exe

Add, edit, or modify authentication settings as appropriate.

Specify Authentication Settings

To specify authentication settings for the client:

  1. Open the Transparent Encryption application.

  2. Click Clients > Clients.

  3. Under Client Name, click the desired client.

  4. Click the Client Settings tab. The Settings text box contains the authentication settings.

    Each line has the format:

    |privilege|/path/to/binary

    Refer to Client Settings Keywords for keywords.

  5. In the Settings box, specify the authentication mechanism.

    Note

    • To delete the settings, delete the content and click Apply.
    • To edit the settings, modify the content and click Apply. When editing the setting strings, follow the format |privilege|binary.
    • To cancel any changes, click Cancel.

  6. Click Apply.

Oracle Database in a Guarded NFS Mount on AIX

To locate your Oracle database in a guarded NFS mount:

  1. Open the Transparent Encryption application.

  2. Under Client Name, click the desired client.

  3. Click the Client Settings tab. The Settings text box contains the authentication settings. Each line has the format:

    |privilege|/path/to/binary

  4. In the Settings text box, add the following entries:

    |vfsnumber|<path to>/oracle
|vfsnumber|<path to>/dbca

    Example:

    |vfsnumber|/u01/app/oracle/dbhome_1/bin/oracle
|vfsnumber|/u01/app/oracle/dbhome_1/bin/dbca

  5. Click Apply.

Client Settings Keywords

The following table lists the keywords that you can enter on the Client Settings tab. These keywords override different authentication requirements:

KeywordDescription
|authenticator|(UNIX only) Authenticates based upon the real user ID (ruid) credentials of a process. The indicates that the given binary is trusted to authenticate users. For example, the sshd process on UNIX is a good |authenticator|. It takes incoming network connections and authenticates the user that attempts to log on to the system. All child processes from this session are trusted as the original user.
|authenticator_euid|(UNIX only) Authenticates based upon the effective user ID (euid) credentials of a process. The keyword is used to authenticate the credentials of a setuid process with the euid value rather than the ruid value.
|vfsnumber|(AIX [all supported]/Oracle 10gR2) Use when Oracle RMAN backups fail on NFS as a result of not receiving underlying file system identifiers. Apply |vfsnumber| to the Oracle binaries directory.
|realfsid|(AIX [All supported]) Use if the cp operation fails while copying files with extent attributes on guarded Veritas file systems. The failure occurs because the underlying file system identifier is not received.
|lock|(Windows only) Specifies an application that cannot be executed on the client. An application defined with lock does not go through an internal policy check. The application is not allowed to run at all.
A default set of applications is locked on Windows clients to prevent their execution and potential failure during bootup. The same effect can be achieved by configuring the resource and process security rule attributes in a policy. However, certain default applications are automatically locked on the Client Settings tab as a precautionary measure. Those applications must be included in the policy.
Sometimes, problems such as installation failure or application lockup occur when installing software on a locked client. In such cases, identify the locked processes, unlock them, and retry installation. The failure goes away. For example: |lock|c:\winnt\system32\msiexec.exe
|exempt|(Windows only) When processes or applications are started, the internal policy and regular policies are checked locally or by the CipherTrust Manager. When a policy check is performed and exempt is applied to the process, a six second timeout is imposed on the check. Without exempt, an application can wait indefinitely for a policy access check to complete, as when the CipherTrust Manager is required but is inaccessible.
If the check times out because the CipherTrust Manager is unavailable for any reason, access is denied. Exempt client processes are also “exempt” from popup messages that describe the occurrence of access violations. An example of what causes such popup messages is an application that tries to memory map a file for which it does not have encryption permission (for instance, memory map with no view ability key on Windows). The only reasons to include exempt in the configuration are shorter wait periods and blocked popup messages.
|su_root_no_auth|(UNIX only) Assigned only to the su process for tracking root users issuing unauthenticated su logins. The |su_root_no_auth|/usr/bin/su host setting in conjunction with |authenticator|/usr/lib/ssh/sshd prevents root from being authorized as another user. Non-root users using su to log on as another user after authentication, that is, after providing a password are not affected.
|path_no_trust|(UNIX only) Any executable path that is marked with a |path_no_trust| client setting marks the process, and all child processes, as not trusted. Non-trusted processes are treated as "User Not Authenticated" to prevent access on user-based policies.
CTE prevents overrides from other client settings authenticators, using the |path_no_trust| status. If a user runs the su command from a non-trusted shell, that new shell is still marked as |path_no_trust|, even if |authenticator|/usr/bin/su is specified in the client settings. The |path_no_trust| feature overrides any and all authenticators under client settings.

The following table shows different results you get when using authenticator or authenticator_euid to verify user identities.

ProductApplicationClient SettingUser
Oracleoracleauthenticator_euid"oracle"
Oracleoracleauthenticator*

* indicates the real uid of the user who starts the application. This means that if the policy is configured to check the user ID, a security rule must be generated for every possible user.

Note

Apply the |authenticator_euid| keyword to the oracle binary on the Client Settings tab to authenticate the oracle user because regardless of who starts the oracle process, the EUID is always oracle.

Configuring Application Authentication Credentials

To configure application authentication credentials:

  1. Open the Transparent Encryption application.

  2. Click Clients > Clients.

  3. Under Client Name, click the desired client.

  4. Click the Client Settings tab. The Settings box displays the default set of system applications that may require authentication entries.

  5. In the Settings box, add, modify, or delete entries to control their access permissions. When you add more processes, you must include the entire path.

    Note

    A keyword such as |authenticator| must be used in front of a process, otherwise, the entry is ignored by the CipherTrust Manager GUI.

  6. Click Apply.

Client users currently logged on to the client must log off and log on again to refresh their user authentication credentials. They can verify the change by logging on to the client, accessing a GuardPoint, and checking the user information in the message logs.

Inheriting Client Settings from a Client Group

To inherit client settings from a client group:

  1. Open the Transparent Encryption application.

  2. Under Client Name, click the desired client.

  3. Click the Client Settings tab.

  4. Select the desired client group from the Inherit Client Setting From drop-down list. This drop-down shows the list of client groups the client is a member of. The drop-down is not available for standalone clients.

  5. Click Apply.

The client now inherits client settings from the selected client group. Refer to Inheritance of Client Group Settings for details on inheritance.

Note

An unregistered client cannot inherit client settings from its client groups.

Re-Sign Settings

If you add another process to the set of trusted applications on the Client Settings tab, enable the Re-sign Settings toggle. This ensures that the new process is signed and authenticated by the client.

Subsequently, when the client settings are pushed to the CTE Agent, the updated settings are re-signed. The Re-sign Settings toggle is turned off (or reset).

To ensure that new processes are signed and authenticated by the client:

  1. Open the Transparent Encryption application.

  2. Click Clients > Clients.

  3. Under Client Name, click the desired client.

  4. Click the Client Settings tab.

    Re-sign Client Settings

  5. In the Settings box, update settings as appropriate.

  6. Turn on the Re-sign Settings toggle.

    Re-sign Client Settings

  7. Click Apply.

Enabling the Re-sign Settings toggle forces a signature update. On subsequent push of the client settings to the CTE Agent, the updated settings are re-signed and the Re-sign Settings toggle is turned off (or reset). If you do not turn on this toggle after adding a new process, the client ignores the newly added process.

Modifying Client Configuration

To modify the client configuration:

  1. Open the Transparent Encryption application.

  2. Click Clients > Clients.

  3. Under Client Name, click the desired client.

    Alternatively, click the expand icon (Expand Icon) to the left of the desired client in the clients list.

  4. In the top right corner, click Expand Icon to expand the mini detail view.

    Linux Client

    Windows Client

  5. Modify the following, as appropriate:

    • Live Data Transformation: Enabled or disabled based on the feature selection during registration. By default, LDT performs rekey operations on the LDT protected GuardPoints as soon as GuardPoints are enabled. To pause LDT rekey operations, click the Suspend Live Data Transformation icon (Suspend Icon). The icon changes to Resume Live Data Transformation (Resume Icon).

      After LDT has been enabled, it cannot be disabled. To remove the feature, you must migrate existing data protected under LDT policies, unregister the client, and delete the client. Then, you can reregister the client without enabling the feature. This allows you reclaim the license for use on another client.

    • Efficient Storage: Enabled or disabled based on the feature selection during registration.

      After efficient storage has been enabled, it cannot be disabled. To remove the feature, you must migrate existing data protected with efficient storage GuardPoints, unregister the client, and delete the client. Then, you can reregister the client without enabling the feature.

    • Encryption Key Protection: Enable or disable protection of encryption keys stored in the cache memory on the CTE client. The field is available to registered clients only.

      When enabled, keys are removed from the cache after three minutes of inactivity and memory is overwritten with random data any time after a key is used.

      When keys are cached in memory, they are encrypted in the cache and only decrypted when used. This adds a small overhead but extra security. The in-memory key cache is held in the operating system kernel and is not accessible to any user-space applications. Furthermore, Thales recommends that CTE only be run on operating systems that have been patched to prevent Meltdown and Spectre attacks. Subsequent releases will prevent the CTE agent from running if patches are not in place.

      If a kernel crash dump is initiated, any clear-text key information (used to derive keys from encrypted cached key counterparts) is erased from memory before the crash dump is taken.

    • Cloud Object Storage: (Non-editable, Linux only) Enabled or disabled based on the feature selection during registration. From the GUI, you can neither disable nor enable the Cloud Object Storage feature. To enable or disable it, register the client again and opt or opt out of the Cloud Object Storage feature. Refer to the CTE Agent for Linux Quick Start Guide for details.

    • File Header Supported (FHS): (Non-editable, Windows only) Enabled or disabled based on the feature selection during Agent installation. When this feature is enabled, you can apply GuardPoints to SMB shares.

      After FHS has been enabled, it cannot be disabled from the CipherTrust Manager. To turn off the feature, you must migrate existing data protected under LDT policies, unregister the client, and delete the client. Then, you can reinstall the client with the LDT on CIFS (File Header Support, FHS) capability turned off, and register with the CipherTrust Manager.

    • Secure Start: (Non-editable, Windows only) Enabled or disabled based on the installed Agent capability. If the Agent supports the Secure Start feature, then this option is enabled, otherwise, the option is disabled.

    • In-place Data Transformation - Device: (Non-editable, Linux only) Enabled or disabled based on the installed Agent capability. If the Agent supports the feature, then this option is enabled, otherwise, the option is disabled.

    • Unlock: Unlock Agent Lock and System Lock.

    • Agent Lock: Lock the contents of the CTE Agent directories on the client.

    • System Lock: Apply an internal policy to the client to lock client system directories, like /var, /bin, /etc. Enabling System Lock automatically enables Agent Lock.

    • Communication Enabled: Whether to enable the client's communication with the CipherTrust Manager. Select to enable, clear to disable communication. By default, the communication is enabled. For manually added unregistered clients, this option is editable if Registration Allowed is selected.

    • Registration Allowed: (Manually added unregistered clients) Whether to allow client's registration with the CipherTrust Manager. Select to allow, clear to deny registration. By default, the registration is not allowed.

    • Password Creation Method: Set the password creation method—Manual or Generate. Refer to Changing Client Password for details.

    • Client Profile: Select a profile for the client. The default profile is DefaultClientProfile. If you did not specify a profile during registration, the client is linked with default profile. To change the client profile, refer to Changing the Profile for details.

  6. Click Apply.

Changing the Profile

To change the client profile:

  1. Open the Transparent Encryption application.

  2. Under Client Name, click the desired client.

  3. In the top right corner, click Expand Icon to expand the mini detail view.

  4. Next to Client Profile, click the profile link (for example, DefaultClientProfile). The Select Profile dialog box shows the current client profile and Rekey Option, Rekey Rate, and Schedule of the selected profile.

    Select Profile

  5. From the Profile drop-down list, select the desired profile.

  6. Click OK. The selected profile is linked successfully.

On this page