Skip to content

Enhancements in Accops Workspace macOS Client version 7.2.1.1043

UK Character Support for Workspace Client Login

Workspace Client login and password management have been enhanced to support UK-specific and extended character sets.

Previously, certain UK special characters were not processed correctly during authentication workflows, resulting in login and password management issues.

The Workspace Client now supports UK special characters in:

  • Username fields

  • Password fields

Users can successfully authenticate with credentials that contain supported UK-specific characters.

Password Change Support

Password change operations have also been enhanced to support UK special characters.

Benefits

  • Improved compatibility with regional and organizational password policies.

  • Successful authentication using credentials containing UK-specific characters.

  • Reliable password update and reset operations.

  • Improved user experience for UK-based deployments and multilingual environments.

Desktop Folder Grouping for VDI Pools

Desktop Pool configuration now includes folder grouping, allowing administrators to organize published desktops into folders to improve workspace management.

This functionality is similar to the existing application folder feature and enables better separation of desktop resources such as Shared Hosted Desktops (SHD) and Virtual Desktop Infrastructure (VDI) desktops.

Location Path
Management Console HyWorks Controller Management Console > VDI > Pools > Add/Edit Desktop Pool wizard > Client Settings tab > Folder Creation

Folder Creation Options

Option Description
None Desktops are published without folder association.
Create New Create a new folder and associate desktops with it.
Use Existing Associate desktops with an existing folder.

Benefits

  • Improved desktop organization.
  • Easier segregation of SHD and VDI resources.
  • Cleaner end-user workspace presentation.
  • Consistent resource grouping across environments

Important Limitations

Constraint Details
No explicit folder management Folder association can ONLY be done through the Add/Edit Desktop Pool wizard.
Folder deletion is not supported Must be handled carefully (no delete option in console).
Application ≠ Desktop folders Application folders cannot be used for desktops, and desktop folders cannot be used for applications.

Power Operation Control for Virtual Desktops

Power Operation Control enables administrators to centrally manage which power-related actions end users can perform on their virtual desktops.

This feature provides granular control over desktop lifecycle operations directly through HyWorks.

Location Path
Management Console HyWorks Controller Management Console > VDI > Pools > Add/Edit Desktop Pool wizard > Client Settings tab > Power Operation Control

Configuration Options

Option Description
Allow All All supported power operations are available to end users, subject to the VM's current power state.
Disable All All power operations are hidden or disabled regardless of the VM's power state.
Allow Limited Only administrator-selected power operations are available, based on the VM's current power state.

Important Restriction

This feature is supported only for single-session desktops.

Power Operation Control is not available for:

  • Multi-session desktops

  • Shared desktop environments

Benefits

  • Centralized administrative control.
  • Reduced risk of accidental user-initiated power operations.
  • Improved compliance with operational policies.
  • Greater flexibility in managing desktop lifecycle actions.

SAML WebView Cache Cleanup After Login Completion

The SAML WebView Cache Cleanup feature allows administrators to control whether the client clears the SAML WebView cache after successful SAML authentication.

This behavior is managed through the Gateway Configuration Service using the globalclientsetting.js configuration file.

The feature provides greater control over SAML session management and helps prevent issues caused by stale authentication data.

Benefits

When enabled:

  • The client automatically clears the SAML WebView cache after a successful login.
  • Stale or cached SAML sessions are removed.
  • Authentication failures caused by outdated session data are reduced.
  • Session conflicts between consecutive logins are minimized.
  • Security is improved by preventing retention of SAML session information.

Default Behavior

  • The feature is disabled by default (flag = false).
  • Cache cleanup occurs only when explicitly enabled in globalclientsetting.js.
  • The setting is applied immediately after the client retrieves the realm configuration details from the Gateway.

Configuration

Configuration Tag in globalclientsetting.js:

Tag Description
CLEAR_WEBVIEW_SAML_CACHE_ON_COMPLETE = true - Clears the SAML WebView cache after successful authentication.
- Prevents issues caused by stale or cached SAML sessions.
- Users must re-authenticate during subsequent SAML sessions.
- Improves security by removing retained session data.
CLEAR_WEBVIEW_SAML_CACHE_ON_COMPLETE = false - Retains the SAML WebView cache.
- Existing session and credential information may be reused.
- Provides faster authentication for repeat logins.
- Maintains existing behavior (default setting).

SAML Login Workflow

  • The user initiates SAML authentication.

  • The SAML WebView dialog is launched.

  • The user completes authentication.

  • Login processing completes successfully.

Cache Cleanup (when enabled)

After successful authentication:

  • The client evaluates the SAML_CACHE_CLEAR setting.

  • If enabled (true), the client invokes: webProfile.clearHttpCache().

  • The WebView cache is cleared before the WebView is closed.

Default WebView Profile Fallback

A fallback mechanism has been added for environments where SAML WebView cache cleanup is disabled.

When cache cleanup is not enabled, the client will use the Default WebView profile instead of a specialized SAML WebView profile that relies on cache-clearing behavior.

Behavior When Cache Cleanup Is Disabled

Configuration

CLEAR_WEBVIEW_SAML_CACHE_ON_COMPLETE = false, or when the setting is not configured.

Result

  • The client does not invoke webProfile.clearHttpCache().
  • Cached HTTP content and session data remain available.
  • Existing SAML session information can be reused during future authentication attempts.

Fallback Logic

When CLEAR_WEBVIEW_SAML_CACHE_ON_COMPLETE is set to false:

  1. The client detects that SAML cache cleanup is disabled.
  2. The specialized SAML WebView profile is not used.
  3. The client automatically falls back to the Default WebView profile.
  4. Authentication continues using the standard WebView configuration.

Benefits of the Fallback

  • Provides consistent behavior when cache retention is required.
  • Eliminates dependencies on SAML-specific WebView profiles designed for cache-clearing workflows.
  • Improves compatibility across different authentication environments.
  • Simplifies WebView profile management and reduces configuration complexity.

Turbo ACL – Traffic Handling and Version Compatibility

Turbo ACL is a security feature enforced jointly by the HySecure Gateway and the client. When enabled, only traffic to explicitly published Turbo ACL ports is permitted. Traffic to non-published ports may be blocked.

When the global block setting is enabled, Turbo ACL now allows traffic on all ports while continuing to enforce any explicitly configured port-based ACL policies.

Reference #70377 Turbo ACL Behavior and Compatibility Guidance

Turbo ACL enforcement is performed by both the HySecure Gateway and the client.

For HySecure Gateway versions 7.1 through 7.3 (prior to SP1), Turbo ACL processing is enabled on clients by default. During these releases, the Gateway management interface does not provide control over client-side Turbo ACL behavior.

As a result, administrators may disable Turbo ACL from the Gateway configuration, while clients continue to receive and process Turbo ACL policies.

Symptoms

In this scenario:

  • Client logs show that Turbo ACL policies are successfully parsed.

  • Traffic to ports not explicitly published through Turbo ACL may be blocked.

  • Applications that use non-Turbo ACL-published ports may fail to connect.

  • Unexpected traffic restrictions may occur even though Turbo ACL appears disabled in the Gateway UI.

Because Turbo ACL enforcement occurs on both the Gateway and the client, configuration mismatches between the two can lead to connectivity issues.

Upgrade the Gateway to HySecure 7.3 SP1 or later.

Beginning with 7.3 SP1, Turbo ACL client behavior is fully integrated with the Gateway management interface.

Benefits

  • Turbo ACL can be managed directly from the Gateway UI.

  • Gateway configuration is automatically propagated to clients.

  • Client-specific disable tags are no longer required.

  • Gateway and client Turbo ACL states remain synchronized.

This is the recommended long-term solution.

Workaround for Gateway Versions 7.1 to 7.3 (Pre-SP1)

If an upgrade to 7.3 SP1 or later is not immediately possible, Turbo ACL processing can be explicitly disabled on the client.

This requires configuring platform-specific client feature-disable tags via the Gateway backend configuration (via SSH access).

Note

  • These tags disable Turbo ACL processing only on the client.

  • They do not disable Turbo ACL enforcement on the Gateway.

  • If Turbo ACL remains enabled on the Gateway, ACL restrictions continue to be enforced, and traffic to non-published ports may still be blocked.

Administrators should therefore ensure that Gateway and client Turbo ACL configurations remain aligned.

Client Feature Disable Tags - HySecure Gateway

Tag Description
VPN_SKIP_MAC_TURBO_ACL=true Configure the global client feature settings (globalclientsetting.js) on the HySecure Gateway backend. Client reconnection is required for the change to take effect.

Verification

After applying the appropriate disable tag and reconnecting the client, verify the following entry in uac.log:

[TURBO-MANAGER] Turbo ACL is explicitly disabled for this platform

This confirms that the client is no longer processing Turbo ACL policies.

Version Compatibility Summary

Gateway Version Gateway UI Controls Client Turbo ACL Client Disable Tags Required
7.1.x No Yes, if client-side Turbo ACL processing must be disabled
7.2.x No Yes, if client-side Turbo ACL processing must be disabled
7.3.x (Pre-SP1) No Yes, if client-side Turbo ACL processing must be disabled
7.3 SP1 and later Yes No

Important

  • Turbo ACL enforcement occurs on both the Gateway and the client.

  • Prior to 7.3 SP1, the Gateway UI did not control client-side Turbo ACL behavior.

  • Client feature: disable tags, only instruct the client to ignore Turbo ACL policies.

  • If Turbo ACL remains enabled on the Gateway, traffic to ports not explicitly published through Turbo ACL may still be denied by the Gateway.

  • Upgrading to 7.3 SP1 or later is the preferred approach for consistent Turbo ACL management.

Disabling ACL enforcement may reduce network security. Turbo ACL should remain enabled whenever operationally feasible and security requirements permit.