Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.
Version: 2.15.0

Lockout Settings

Overview​

When Ransomware Defender raises a security event at Major or Critical severity, the system's response is to lock out the affected user — removing their access to file shares across all managed clusters. This page explains how lockout works, how it differs between SMB, NFS, and ECS, and what the known limitations and edge cases are.

User lockout behavior by mode​

The lockout behavior depends on the Lockout Behavior setting configured in Detection Controls → Settings → Response Settings. See Threat Detection and Severity Settings for a description of each mode.

Monitor mode — no lockout​

No lockout is applied at any severity level. Events appear on the Threat Detections page for manual review only. This mode is appropriate during initial deployment and baseline tuning.

Enforcement mode — delayed lockout at Major​

Events can only reach Warning or Major severity in this mode — see Monitor mode vs. enforcement mode. There is no Critical severity to reach, so there's no immediate-lockout case in this mode.

At Major severity: A delayed lockout countdown begins. The duration of the countdown is configurable in Detection Controls → Settings → Event Severities. During this window, administrators can:

  • Stop the lockout timer — cancels the pending lockout. The event moves to Acknowledged state. Use this when you confirm the activity is benign before the timer expires.
  • Lockout Now — immediately applies the lockout without waiting for the timer to expire. Use this when you confirm the activity is malicious and want to contain it sooner. If neither action is taken before the timer expires, the lockout is applied automatically.

Critical mode — Warning, Major, and Critical severity​

Critical mode changes which severities can be raised, not what each severity does once raised — see Critical mode. Each severity behaves as it does in any other mode:

  • At Warning severity: No lockout is applied. The auto-close countdown runs as normal.
  • At Major severity: A delayed lockout countdown begins, exactly as described for Enforcement mode above.
  • At Critical severity: Lockout is applied immediately with no countdown window. This is a non-negotiable containment action — the system determines that the pattern of activity is severe enough to require instant isolation.

What lockout does​

When a lockout is triggered for a user, the system performs the following actions simultaneously:

  1. Applies a DENY READ permission to all SMB shares the affected user has access to, across all managed clusters. This is applied at the share permission level, not the file level.
  2. Takes snapshots of all accessible SMB share paths (and NFS if configured) subject to the snapshot budget. These snapshots serve as recovery points if data has been corrupted. See Snapshot Settings for the full snapshot configuration reference.
  3. Logs the lockout to the event's Activity Log tab with a precise timestamp and a list of every share and cluster that was locked. The lockout covers all clusters managed by Eyeglass, not just the cluster where the suspicious activity was detected. This is intentional — if a credential is compromised, it poses a threat across the entire managed environment.

SMB lockout​

SMB lockout is the default and primary lockout mechanism. It works by applying an explicit DENY READ ACE (Access Control Entry) to every SMB share the user had access to at the time of detection.

Share access is determined by the user's Active Directory group membership. The system resolves the user's groups at lockout time and applies the deny permission to all shares those groups can access.

To verify a lockout was applied correctly: Navigate to the Assets tab on the Investigate & Recover page. You should see a DENY READ entry for the affected user's SID on each locked share.

To restore access: Use Take an Action → Restore User Access on the Threat Detections page or the Investigate & Recover page. This triggers a background job that removes all DENY permissions that were applied during the lockout. The Job is visible in the Jobs section of the left sidebar.

If your environment spans multiple Active Directory domains, see AD Lockout Planning for how the Everyone group affects lockout scope.

NFS lockout​

NFS lockout is disabled by default and is not recommended for most environments. Before enabling it, read this section carefully — the operational impact is significantly different from SMB lockout.

How NFS lockout works​

NFS does not use the same ACE-based permission model as SMB. Instead, NFS access is controlled at the export level using IP addresses. When a lockout is triggered for an NFS source:

  1. The source IP address is extracted from the audit message.
  2. That IP is removed from all affected NFS exports and the exports are re-saved.
  3. This effectively blocks the NFS host from mounting those exports. This is an IP-level block, not a user-level block. Every client on that IP address — and every application running on that host — loses access to the export simultaneously.

NFS lockout is not user-aware​

Unlike SMB, NFS lockout cannot isolate a single user. If your environment uses Kerberos-authenticated NFS, authentication happens at a higher layer than what the system can act on. When a lockout fires, it blocks the entire source IP — meaning all users and all processes on that host are locked out, not just the user whose activity triggered the event.

Operational impact when enabled​

Blocking an NFS IP causes immediate, hard disruption to the affected host:

  • NFS mount hangs — when the export is removed, the NFS mount becomes unresponsive. All I/O on the client pauses. The hang persists until access is restored.
  • Application errors — any application with open file handles on the locked export continues to reference those files and receives I/O errors.
  • Manual remount required — after access is restored, clients typically need to manually remount the NFS share. An automatic reconnect does not occur.
  • Application restarts may be needed — some workloads require a full application restart to recover cleanly from a lost NFS session.

Data protection without NFS lockout​

Even with NFS lockout disabled, the system still takes automatic snapshots of NFS exports when a security event is detected. This means your data is protected for recovery regardless of whether the lockout is enabled. You can recover affected files from these snapshots through Recovery Manager.

This is the primary reason NFS lockout is disabled by default — the snapshot-based recovery path provides data protection without the operational disruption of blocking the entire NFS host.

Recommendation​

Do not enable NFS lockout if any of the following apply to your environment:

  • Applications require seamless access recovery without manual intervention.
  • Workloads are sensitive to file handle expiration or NFS session interruption.
  • You use Kerberos-authenticated NFS (per-user enforcement is not possible).
  • Your NFS hosts run multiple applications or serve multiple users.

Instead, rely on the automated NFS snapshots for data recovery and use the event triage workflow to investigate and respond to detections involving NFS activity.

CLI commands​

To set NFS events to monitor mode (default recommended — detects and logs NFS activity without triggering a lockout):

igls rsw nfsevents set --enabled=monitor

To enable NFS lockout (only if you have reviewed the operational impact above and accept it):

igls rsw nfsevents set --enabled=true

To disable NFS lockout:

igls rsw nfsevents set --enabled=false

ECS object storage lockout​

ECS lockout works differently from both SMB and NFS. Rather than operating at the share or export level, it acts directly on the authenticated user identity — either an IAM user or an ECS bucket object user — using the ECS management API.

How ECS lockout works​

ECS audit events identify the user performing object operations by their authenticated identity. When Ransomware Defender detects suspicious activity and a lockout is triggered:

  1. The user identity is extracted from the ECS audit message — either an IAM user (federated identity, typically AD-backed) or an object user (native ECS S3-style credential).
  2. Eyeglass calls the ECS management API to revoke that user's access across all managed ECS buckets — lockout cannot be scoped to a single bucket.
  3. The lockout is recorded in the event's Activity Log tab with a timestamp and the affected ECS cluster details.

User types and behavior differences​

ECS Ransomware Defender supports two user types, and they behave differently in some areas:

IAM userObject user (bucket user)
LockoutSupported — access revoked via ECS APISupported — access revoked via ECS API
Affected objects list in GUISample shown; full CSV not generatedFull CSV generated
Learned ThresholdsNot supported — cannot be updated via false positive or auto-learningSupported
Recovery ManagerSupportedSupported — bucket users must be added to Inventory to appear in Recovery Manager

Important: Learned thresholds cannot be applied to IAM user events. If an IAM user account generates false positives, the recommended approach is to add that user to the Monitor Only list rather than relying on auto-learning.

Scope of ECS lockout​

ECS lockout applies to all buckets managed by Eyeglass on the affected ECS cluster — it cannot be scoped to individual buckets. This is a platform constraint: ECS user credentials operate at the namespace and cluster level, not the individual bucket level.

If the affected user had access to buckets containing unrelated data, all of those buckets are inaccessible until the lockout is restored.

Restoring ECS access​

To restore an ECS user's access, use Take an Action → Restore User Access on the Threat Detections page, exactly as with SMB lockout. Eyeglass calls the ECS management API to re-enable the user's credentials across all managed buckets.

ECS versioning and recovery​

Unlike NFS — where snapshots are the primary protection mechanism because lockout is disabled by default — for ECS, both lockout and version-based recovery are available together. There is no filesystem-style snapshot mechanism on ECS; recovery relies entirely on bucket versioning.

ECS recovery uses bucket versioning rather than filesystem snapshots. Recovery Manager restores objects to their most recent pre-attack version using ECS object versions. Bucket versioning must be enabled on the ECS cluster for Recovery Manager to function.

To display the Earliest Recoverable Version Time column in Recovery Manager for ECS, set the following parameter in /opt/superna/sca/data/system.xml (inside the <process> tag):

<versioningEnabled>true</versioningEnabled>

When set to false, the Bucket Versioning Status column is shown instead.

Note: ECS Recovery Manager is currently available in the legacy UI only. The new Cyber Recovery Manager UI does not yet have an ECS view. Use the legacy UI for ECS object recovery operations.

ECS lockout limitations​

ECS lockout applies to all buckets, and IAM users have reduced capabilities: ECS lockout cannot be scoped to individual buckets — all managed buckets are locked when a user event triggers a lockout. Additionally, IAM user events do not support Learned Thresholds or full CSV export of affected objects. Place IAM users in Monitor Only mode if automated lockout is not appropriate for those accounts.

Limitations and known issues​

SMB variable expansion in share paths: SMB shares that use variable expansion in their path are only partially supported. Only %U (username variable) is supported for snapshot creation on variable-expansion paths. Other variables do not expand correctly during the snapshot step.

NFS lockout causes full host disruption, not user isolation: When NFS lockout is enabled, the entire source IP is blocked — not just the triggering user. All processes and users on that host lose NFS access simultaneously, mounts hang, and manual remount is required after restore. This is why NFS lockout is disabled by default. See NFS lockout for the full operational impact and recommendation.

Lockout scope is cluster-wide: The lockout applies to all shares the user can access across all managed clusters, not just the shares where suspicious activity was observed. In environments where a large number of shares are accessible to any given user, this can result in broad disruption to a legitimate user if the event is a false positive.

Active Directory group resolution: Group membership is resolved at the moment the lockout is triggered. If a user's group membership changes between detection and lockout, the lockout may not cover all expected shares (if the user was removed from a group) or may cover unexpected shares (if the user was added to a group during the detection window).

Restore access job failures: In some environments, the restore access job may partially fail due to transient AD or cluster API errors. If the job completes with errors, individual shares that failed to restore are logged in the Activity Log tab with the specific error. Re-run the Restore User Access action to retry failed share restores. Check the AEC_CONFLICT error specifically — this indicates a conflicting ACE that must be resolved before the restore can complete.

ECS lockout applies to all buckets, and IAM users have reduced capabilities: ECS lockout cannot be scoped to individual buckets, and IAM user events do not support Learned Thresholds or full CSV export of affected objects. See ECS lockout limitations for the full operational impact and recommendation.

Restoring user access after lockout​

Restoring access is a deliberate, administrator-initiated action. The system does not automatically restore access at any point.

Before restoring access, confirm:

  • You have reviewed the Items & Recovery tab and understand what files were affected.
  • You have reviewed the Activity Log tab and understand the sequence of events.
  • The user's machine has been scanned and cleared, or you are confident the activity was not malicious.
  • You have collected any evidence needed for your incident response process. To restore access:
  1. Navigate to the event on the Threat Detections page.
  2. Click Take an Action → Restore User Access (or from the Investigate & Recover page).
  3. The system starts a background job to remove the DENY permissions from all locked shares.
  4. Monitor the job status in the Jobs section of the sidebar.
  5. Once complete, verify in the Assets tab that the DENY entry has been removed.
  6. Confirm with the user that they can reconnect to their shares. After restoring access, the event moves to Restored Access state. You can then close the event using the Close Event wizard.

See also​