Skip to main content
Version: 2.13.0

What's New?

What's New - 2.13.0​

This release introduces several improvements to enhance system reliability, configurability, and monitoring capabilities.

New Default License Behavior​

Prior to version 2.13.0, Eyeglass automatically applied licenses (auto-licensing) to managed devices in two scenarios:

  • Adding a New Managed Device: Eyeglass would automatically license the device for each installed application (e.g., Eyeglass DR, Ransomware Defender, Easy Auditor, etc.) if licenses were available.
  • Loading a New License Archive: Eyeglass would automatically attempt to license any registered but unlicensed managed devices for applications included in the new archive.

While this simplified the licensing process, it could result in incorrect license assignments. For example, if you had two managed devices (production and backup) but only one Ransomware Defender license intended for production, adding the backup device first would assign the license to the wrong device.

Although you could correct this using the License Management view's License Devices tab, the auto-licensing behavior could create unnecessary administrative overhead.

What's Changed​

Starting with version 2.13.0, auto-licensing is deactivated by default. This means:

  • Newly added managed devices will not be automatically licensed for any installed applications, even if licenses are available
  • Loading a new license archive will not automatically apply licenses to registered but unlicensed managed devices

This change gives administrators explicit control over which devices receive licenses, reducing the risk of incorrect assignments.

Action Required

After adding a new managed device or loading a new license archive, administrators must manually assign licenses using the License Management view.

Impact of the New Behavior​

No Automatic Inventory Collection​

The most visible impact is that automatic inventory collection will no longer occur for newly added devices. Inventory collection only begins after you manually assign the appropriate license status to the managed device.

This applies to all functionality provided by installed applications—nothing will start automatically until licenses are explicitly assigned.

Editing Managed Devices​

When editing a registered managed device, the device returns to an unlicensed state and must be manually reassigned licenses.

In versions prior to 2.13.0, auto-licensing would automatically re-establish licensing after editing. With the new default behavior, you must manually reassign licenses after any device edits.

Managing Licenses with the New Behavior​

Adding a New Managed Device​

When you add a new managed device to Eyeglass:

  1. The device is registered but remains unlicensed for all installed applications
  2. No Eyeglass functionality is applied to the device until you assign licenses
  3. To license the device:
    • Open the License Management view
    • Select the License Devices tab
    • Apply the license status for each installed application as needed
    • If the device should not use a specific application, leave the state as shown or set it to user-unlicensed

Loading a New License Archive​

When you load a new license archive into Eyeglass:

  1. The new license grants are added to Eyeglass
  2. Existing registered but unlicensed devices remain unlicensed
  3. To apply the newly available licenses:
    • Open the License Management view
    • Select the License Devices tab
    • Apply the appropriate license status to registered devices as needed
    • If a device should not use a specific application, leave the state as shown or set it to user-unlicensed

After Editing a Managed Device​

When you edit a registered managed device:

  1. The device returns to an unlicensed state
  2. You must manually reassign licenses after completing the edit
  3. Follow the same process as adding a new device:
    • Open the License Management view
    • Select the License Devices tab
    • Reapply the license status for each installed application

Reactivating Auto-Licensing​

If you prefer the previous auto-licensing behavior, you can reactivate it by modifying the Eyeglass configuration:

Steps to Enable Auto-Licensing​

  1. Connect to the Eyeglass appliance

  2. Navigate to the directory:

    cd /opt/superna/sca/data

  3. Copy the configuration file SLMConfig.xml if not already present:

    cp /opt/superna/sca/conf/SLMConfig.xml /opt/superna/sca/data/SLMConfig.xml

  4. Open the file for editing:

    vim /opt/superna/sca/data/SLMConfig.xml

  5. Find the entry:

    <AutoLicensing enabled="false">

  6. Change it to:

    <AutoLicensing enabled="true">

  7. Save the file and restart Eyeglass

Configuration Notes
  • Changing this flag does not immediately impact existing registered managed devices
  • The change takes effect when:
    • A new managed device is added to Eyeglass
    • A new license archive is loaded
  • These actions will trigger auto-licensing for unlicensed devices with installed applications matching the available license grants

Migration Considerations​

For Existing Deployments​

If you're upgrading from a version prior to 2.13.0:

  • Existing licensed devices remain licensed—this change only affects new licensing operations
  • Review your device addition and license loading procedures to include the manual licensing step
  • Train administrators on the new License Management workflow

For New Deployments​

If you're deploying Eyeglass 2.13.0 or later for the first time:

  • Plan for manual license assignment as part of your device onboarding process
  • Consider whether auto-licensing better suits your environment and enable it if appropriate
  • Document your licensing workflow for your operations team

Improved Security with Two-Factor Authentication​

Two-Factor Authentication (2FA) using Time-based One-Time Password (TOTP) apps is now available for Eyeglass login, significantly enhancing security and protecting against unauthorized access.

Key Benefits:

  • Stronger Authentication: Requires users to verify identity using a second factor beyond passwords
  • Prevents Credential Compromise: Significantly reduces the risk of unauthorized access from stolen or compromised credentials
  • Enterprise-Grade Security: Meets modern security requirements and improves customer trust
  • User-Friendly Experience: Maintains a simple, intuitive login process while adding robust protection

What's Included:

  • TOTP-based authentication compatible with popular authenticator apps (Google Authenticator, Microsoft Authenticator, Authy, etc.)
  • Streamlined enrollment process for users
  • Secure recovery mechanisms
  • Administrative controls for 2FA management

Snapshot Budget Improvements​

Snapshot budget handling has been enhanced to provide more predictable and controlled snapshot behavior during ransomware safeguard workflows (RSW). The system now evaluates not only the current snapshot count, but also the snapshots that are about to be taken as part of the event workflow.

This ensures that snapshot operations never exceed the configured budget and behave consistently across different user and critical-path snapshot scenarios.

How It Works​

  • Let SB = Snapshot Budget
  • Let X = Current number of snapshots on the cluster
  • Let C = Number of critical snapshots required for the RSW event
  • Let U = Number of user snapshots required for the RSW event

The logic is as follows​

  • If X > SB, then no snapshots are taken. This is the same as before.
  • If X + C > SB, then no snapshots are taken, because taking critical snapshots would exceed the budget.
  • If X + C < SB and X + C + U > SB, then only critical path snapshots are taken. No user snapshots are taken, as that would exceed the budget.
  • If X + C + U < SB, then snapshots are taken as usual. The budget is not exceeded.

Benefits​

  • Prevents unexpected snapshot failures during RSW events
  • Ensures cluster stability by strictly honoring the snapshot budget
  • Improves predictability and consistency across different snapshot workflows

Recommendation​

If your environment is designed so that all users have access to all shares and permissions are primarily managed at the NTFS level AND the number of shares exceeds the snapshot-quota threshold, we recommend disabling all user-initiated snapshots for both SMB and NFS. Instead, we advise enabling critical-path snapshots only. This ensures that your most important data remains consistently protected and that the system can reliably prioritize essential snapshot operations.

How to identify your critical-path snapshots?​

Critical-path snapshots can be configured at the share level, giving you fine-grained control over which datasets receive guaranteed snapshot protection.

Include shares containing sensitive, regulated, or high-value data​

Examples​

  • Financial records, HR records,
  • Legal or compliance-governed data
  • Executive or departmental data with tight RPO/RTO requirements

Prioritize shares that directly impact business continuity. These include​

  • Application or service data required for daily operations
  • File shares supporting production workflows

Consider redundancy gaps​

If a dataset is not backed up, replicated, or protected by application-level mechanisms, it should be treated as critical.

Improved Webhook Testing​

The Webhooks Test button has been updated to send realistic, schema-compliant payloads that align with the current payload version.

What's Improved:

  • Accurate Testing: Webhook test payloads now match actual production payloads
  • Schema Compliance: Ensures payloads conform to the current webhook schema version
  • Better Validation: More reliable testing of webhook integrations and endpoints
  • Improved Debugging: Realistic test data helps identify integration issues before production use

This enhancement ensures that webhook integrations can be thoroughly validated during setup and configuration, reducing the risk of issues when real events are triggered.

Vault-Contained Scheduling for ECS AirGap​

AirGap scheduling can now be fully contained within the Vault Agent, eliminating dependency on the Superna core appliance (Eyeglass) for schedule management.

Security Benefits:

  • Complete Isolation: Scheduling data remains within the vault, maintaining AirGap security posture
  • Prevents Unauthorized Access: Schedule information cannot be viewed or modified outside the vault
  • Mitigates Insider Threats: Protects against malicious or misconfigured operators attempting to alter replication schedules
  • Enhanced Data Protection: Ensures complete in-vault control over all replication operations

How It Works:

When vault-contained scheduling is enabled, all scheduling configuration and execution is handled by the Vault Agent. The Eyeglass appliance has no visibility into or control over replication schedules, maintaining true air-gapped operation.

New CLI Command: Node Composition Dump​

A new CLI command was added to export managed device node composition in JSON format:

igls manageddevice composition get --log=/tmp/nodes.json

This command outputs structured node information (model, ID, and capacity) for registered managed devices. The JSON format allows future extensibility and is used by the Log Parser and backup processes.

OpenSUSE 16.0: Windows Domain Membership via YaST2 Removed​

The Windows domain membership option is no longer available in YaST2 for OpenSUSE Leap 16.0 OVA images because the yast2-samba-client module has been removed.

To join a Windows domain, customers must now use the following commands:

Discover the domain​

sudo realm discover your-domain.com

Join the Windows domain​

sudo realm join --user=administrator your-domain.com

Verify membership​

sudo realm list

This new method replaces the previous YaST2-based configuration.

Improvements to Restore Script​

When restoring with the anyrelease flag, the restore process now includes comprehensive database restoration capabilities. This enhancement ensures that:

  • All information in the database is restored during anyrelease operations
  • Webhooks are properly restored during anyrelease restore
  • Additional configuration information is preserved and restored

This improvement provides more complete system recovery when performing cross-version restores.

Kafka Poll Timeout Now Configurable​

A new configuration parameter allows administrators to customize the Kafka poll timeout for Eyeglass operations.

Configuration Details:

A new value kafka_pollwait_millisecs can be added to /opt/superna/sca/data/system.xml to configure the Kafka poll timeout. The default poll timeout is 1000 milliseconds.

Usage:

Kafka topics are polled during:

  • Recovery Manager operations
  • User activity checks for ransomware events

Configuration Example:

<rsware>
    <kafka_pollwait_millisecs>1000</kafka_pollwait_millisecs>
    <!-- etc... -->
</rsware>
info

Adjust this value based on your environment's network latency and Kafka cluster performance characteristics. Lower values provide faster polling but may increase CPU usage, while higher values reduce polling frequency.

Memory Monitoring on ECA Now Enabled​

Memory monitoring is now enabled by default for critical ECA containers, providing proactive diagnostics and troubleshooting capabilities.

Monitored Containers:

  • turboauditor
  • fastanalysis
  • kafka
  • zookeeper
  • evtarchive

Automatic Log Capture:

When memory usage in a monitored container exceeds the threshold (default: 95%), the system automatically:

  1. Captures logs from the affected container
  2. Dumps the logs into the eca_logs directory for analysis
  3. Enables faster troubleshooting and root cause analysis

Customizing the Memory Threshold:

The default memory threshold of 95% can be customized by adding the following to eca-env-common.conf:

export CONTAINER_MEM_THRESHOLD=<value>

Where <value> is your desired memory threshold percentage (e.g., 90 for 90%).

tip

This proactive monitoring helps identify memory-related issues before they impact system performance or availability. Review the eca_logs directory periodically as part of your maintenance routine.

Configurable Delay Between SPN Operations​

This release introduces enhanced Service Principal Name (SPN) handling during failover orchestration, providing improved control and visibility for Active Directory operations. A configurable delay has been added between SPN operations to help prevent Active Directory replication conflicts.

Configuration:

The new spnCreateDeleteWait setting allows you to specify a delay (in seconds) between SPN delete and create operations. This setting is configured in the system.xml file:

<readinessvalidation>
   <spnCreateDeleteWait>N</spnCreateDeleteWait>
</readinessvalidation>
Note

'N' represents the delay in seconds.

Configuration Locations:

  • conf/system.xml - Default values
  • data/system.xml - User overrides
  • Default value: 0 seconds (no delay)

Behavior:

The delay is applied between each SPN delete and create operation during cluster failover. Separate delays occur for both source and target cluster SPN operations:

  1. Delete source SPNs → Wait N seconds → Create source SPNs (with igls-original prefix)
  2. Delete target SPNs → Wait N seconds → Create target SPNs (with original name)

Delay operations are logged to failover logs with the message: "Delay for AD replication - N seconds"

Note

If the delay value is set to 0 seconds in system.xml, the delay message will not appear in the logs.

Enhanced SPN Logging​

All SPN operations now log both FQDN and short name formats, providing improved visibility for debugging and audit trails during failover orchestration.

Enhanced Log Information:

  • FQDN format: HOST/cluster-name.domain.com
  • Short name format: HOST/cluster-name
  • Computer account information: Shows which Active Directory machine account is targeted (e.g., ISI-AC-51, ISI-AC-52)

Benefits:

  • Improved visibility for debugging SPN-related issues
  • Complete audit trail of all SPN operations during failover
  • Enhanced troubleshooting capabilities for Active Directory integration

Configurable RSW Username Format​

The RSW username format command syntax has been updated for consistency with other CLI commands.

Command Update:

Previous syntax:

igls rsw usernameformat --format=UPN/DLLN
igls rsw usernameformat --format=UPN

New syntax:

igls rsw usernameformat set --format=UPN/DLLN
igls rsw usernameformat set --format=UPN

This command controls the username format (UPN/DLLN: user@domain / domain\user) used across RSW events, snapshots, and lockout notifications.

Note

Update any existing scripts to use the new set subcommand.

Important Upgrade Considerations​

  • Review system requirements and compatibility before upgrading
  • Plan for 2FA enrollment if enabling this feature post-upgrade
  • Back up all configurations before starting the upgrade process
  • Schedule appropriate maintenance windows for production systems
  • Test vault-contained scheduling in a non-production environment before enabling in production

What's New - Threat Hunting v1.1.1​

The latest version of Threat Hunting introduces a streamlined automated installation workflow, making deployment faster and easier than ever.

What's New - Threat Hunting v1.1.1

Discover the new automated installation workflow and enhanced deployment capabilities in Threat Hunting v1.1.1.

See What's New

Release Notes​

These release notes contain detailed information on fixes, known issues, and limitations in this version.

Review this document to understand the current state of the release.

Release Notes

List of issues, known limitations, and items tracked in this release.

See More

Need Help?​

If you have questions or need assistance with upgrade:

Contact Support

Reach out to Superna Support for upgrade guidance, configuration assistance, or troubleshooting help.

Get Support