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

Data Auditing

Overview​

Data Auditing provides tools to search, analyze, and monitor file system activity across your Dell PowerScale clusters. Use it for forensic investigation after a security event, compliance reporting, tracking specific user or path activity, or real-time monitoring of live file operations.

PowerScale only

Data Auditing is not available for Dell ECS object storage. It requires the PowerScale audit stream that ECS environments don't produce.

Navigate to Data Auditing in the left sidebar under Data Security.

The page has four tabs:

TabPurpose
Queries & ReportsBuild, run, save, and schedule audit queries across the cluster.
Where Did My Folder Go?Quickly locate recently deleted or moved folders and files by path and time window.
WireTapStream file system events in real time, filtered by path, user, file extension, or event type.
Bulk IngestLoad historical audit data from ECA backup files for a specific date.

Queries & Reports tab​

The Queries & Reports tab is the primary audit search interface. It lets you query the audit database using a range of filters, save queries for reuse, schedule recurring reports, and review the complete history of all report runs.

Page layout​

The left panel lists your queries in two groups:

  • Built-in Queries — a set of pre-configured queries provided by Superna, covering common audit scenarios such as top data users, user access summaries, deletion reports, and compliance searches. Built-in queries can be run but not edited or deleted.
  • Custom Queries — queries you have defined and saved. Each entry shows the target device and path, the run type badge (Manual or Scheduled), and the time since the last run. The right panel shows All Reports — every report run across all queries, with status, query name, completion time, run type, record count, and duration. Use the Status, Report Type, and Run Type filter dropdowns above the list to narrow the results, or use the search field to find a specific report by name.

Report statuses​

StatusMeaning
QueuedThe report is waiting to start.
RunningCurrently executing. A progress counter shows records processed.
SuccessCompleted and returned results.
FailedEncountered an error. Review query configuration and cluster connectivity.
CanceledManually stopped before completion.

Creating a query​

Click + Create Query at the top of the left panel to open a menu listing the built-in queries (see Built-in queries below) plus a Create Custom Query option. Select Create Custom Query to open the filter configuration:

Query Name Required. Letters and numbers only — no spaces or special characters. The query cannot be saved until a valid name is entered.

User Name Leave empty to search across all users. To search for a specific user, enter their username in user@domain or DOMAIN\user format — the domain portion must be uppercase. The system resolves the name to an Active Directory SID, which is used to find SMB audit events.

Path Select the cluster and enter or browse to the directory path to search. Choose a path as close as possible to where the relevant activity occurred. Avoid broad paths like /ifs — they significantly increase query time and return volume.

Event Type Defaults to All Events — the slowest option. Use the dropdown to narrow to specific event types; fewer event types produce faster results, so narrow this before running a broad query.

Extension Filter by file extension. Enter the extension without the leading period — for example pdf, not .pdf. Useful for tracking access to specific file types such as spreadsheets, PDFs, or executables.

Time Range Choose from:

  • Days in the past (for example: last 7 days)
  • A specific day
  • A custom date and time range

Always use the narrowest time range that covers your investigation window. For large time ranges, break the query into smaller sub-ranges and combine the results.

Max Results Default maximum is 50,000 records. The system supports up to 1 million events, but large result sets slow the query and produce large CSV export files. Refine other filters before raising this limit.

Email Notification (optional) When enabled, a notification is sent on report completion — even if no results were returned. Disable for ad hoc queries where email confirmation is not needed.

Click Save & Run to save the query and execute it immediately.

Built-in queries​

Built-in queries are pre-configured searches for common operational and compliance use cases. They are available under the Built-in Queries group in the left panel.

To run a built-in query, click it in the left panel to load its configuration, then click Save & Run. You can adjust filters such as time range and path before running, but you cannot save changes to the built-in query itself.

Each query's card in the left panel also has quick-action icons — Run to re-execute it directly without reopening the query builder, plus Duplicate and Delete for custom queries.

ReportPurposeParametersNotes
Stale User AccessBuilds a list of users who can mount SMB shares (based on AD group membership) and calculates the last read or write for each share they have access to. Helps identify users who have share access they no longer use.SMB share, time period to analyzeLong-running on large audit databases or large AD user counts — can take hours.
User AccessMaps users and AD groups to SMB share access, to determine excessive permissions or validate existing share access. AD groups can be expanded to a list of individual users.SMB shareRun time increases with AD user/group count.
Employee ExitShows all files a specific user accessed, by day, over the last 30 days — typically run as part of an HR offboarding process before an employee's last day.User (user@domain or DOMAIN\user — resolution fails if the SID cannot be found), clusterIn high audit-event-rate environments, a full 30-day window may not complete, or results may be capped at 10,000 records. If the built-in report doesn't finish, narrow the window or reproduce it as a custom query with a shorter time range.

These three names match the product's Create Query menu labels verbatim. Note the interface uses two related but different labels for the first one: the menu item is named Stale User Access, while the query's card is tagged with the shorter category label Stale Access — the tag is the category, the name above is the query itself.

Pair Stale User Access and User Access for access reviews

The Stale User Access and User Access built-in queries are typically most useful together: run User Access first to see who currently has access to a share, then Stale User Access to see which of those users haven't actually used that access recently. Together they give you both sides of a least-privilege access review — who can get in, and who's actually using that access.

Additional built-in categories include per-table row counts (useful for capacity/performance review, can run for hours — schedule off-peak) and general excessive-permissions/top-data-consumer summaries. The full current list is visible in the interface once your clusters are connected.

Saving and scheduling queries​

Click Save Query As to store the current configuration under a name of your choice. The query appears in the Custom Queries group and can be run, edited, or scheduled.

To schedule a query:

  1. Save the query using Save Query As.
  2. Select the saved query in the left panel.
  3. Open the Report Schedule section within the query configuration.
  4. Choose a recurrence frequency.
  5. Confirm the schedule. Scheduled queries show a Scheduled badge in the query list and in the report history.
Known issue — Built-in Queries cannot be scheduled in the New GUI

Scheduling is currently only available for built-in queries in the Old (legacy) GUI. In the New GUI, scheduling works for custom queries/reports, but not yet for built-in queries. To schedule a built-in query today, use Save Query As first to create a custom copy, then schedule that copy as described above. Direct scheduling of built-in queries in the New GUI is planned for a future release. See Release Notes — Known Issues.

Viewing and downloading report results​

In the All Reports panel, click the three-dot menu (...) on any completed report row for Download (CSV) or Delete. There is no report viewer in this product — CSV is the only way to review results, and exports contain the full result set up to the configured Max Results limit.

Filtering CSV reports in Excel​

Microsoft Excel column filters let you narrow a downloaded CSV report by date and time, file extension, path, and other columns, beyond what the query builder offers.

  1. Open the CSV file in Excel and enable the column filter on the heading row (row 1).
  2. To filter by time, set the date and time column to a custom number format that includes seconds, for example yyyy-mm-dd h:mm:ss AM/PM.
  3. Open the date and time column filter and use Before, After, or Between to filter with one-second granularity.
  4. To find all files with a given extension, filter the file extension column.
  5. To match part of a path, open the path column filter and choose Contains. Any path that includes the text you enter is matched.
  6. To combine criteria, apply filters on several columns at once, for example a time range, an extension, a partial path, and an access zone.

Where Did My Folder Go? tab​

Where Did My Folder Go? is a focused search tool for locating deleted or moved folders and files. Use it when a user reports that content has disappeared and you need to trace what happened to it quickly, without constructing a full audit query.

  1. In the Path field, select a cluster and enter or browse to the directory path you want to investigate — for example, /ifs/data.
  2. Set the Time Frame: choose a duration unit (Hours or Days) and enter a value — for example, In the last 4 Hours.
  3. Select the Data Type:
    • Folders — search for folder-level changes.
    • Files/Objects — search for individual file changes.
  4. Check Show Deleted Items to include objects that were deleted within the search window.
  5. Click Search. Results are limited to 5,000 entries per search. If the maximum is reached, narrow the time frame or path to get a more precise result set.

Click Download CSV to export the results for offline analysis or to share with a user.

WireTap tab​

WireTap streams file system audit events in real time for a selected cluster and path. Use it for live monitoring during an active investigation, to observe what a specific user is doing right now, or to confirm that audit events are flowing correctly from a cluster.

Casing is intentional

This page spells the tab/feature name WireTap, but the panel and buttons within it (Wiretap Configuration, Start Wiretap, Stop Wiretap, Save Wiretap, Saved Wiretaps) use Wiretap, matching the in-app labels. This is a deliberate distinction between the feature name and the UI element labels, not an inconsistency to fix.

Configuring a WireTap session​

In the Wiretap Configuration panel:

  1. Path to Monitor — Click the field to select a cluster, then enter or browse to the path you want to monitor.
  2. User (optional) — Enter an AD username in DOMAIN\user format to filter the stream to events from that user only. For example: AD5\aneta.
  3. File Name (optional) — Filter by filename or a wildcard extension pattern, per the in-app placeholder text — for example: budget.xlsx or *.docx.
  4. Event Types (optional) — Use the dropdown to select which event types to include.
  5. Subfolders — Checked by default, so events from all subdirectories under the monitored path are included unless you clear it. A WireTap started on a broad path like /ifs with Subfolders left on streams events from everything below it — narrow the path first if you only need one directory. Click Start Wiretap to begin streaming. Events appear as they are processed by the ECA. Click Stop Wiretap to end the session.

Saving a WireTap configuration​

Click Save Wiretap to store the current configuration for future reuse. Saved configurations appear in the Saved Wiretaps list at the bottom of the tab, showing the path, filters, and date last used. Click any saved configuration to reload it, then click Start Wiretap to begin.

Note: WireTap shows events from the moment the stream starts — it does not display historical events. To search past activity, use the Queries & Reports tab.

Bulk Ingest tab​

Bulk Ingest loads historical audit data from ECA backup files for a specific PowerScale cluster and a single target date. Use it when audit data is missing from the database — for example, after an ECA outage — and you need to make that data available for querying.

When to use Bulk Ingest​

  • The ECA experienced downtime and audit events from that period are not in the database.
  • A cluster was recently added to the managed environment and you need historical data from before it was connected.
  • A compliance query requires coverage of a period that predates your ECA's continuous ingestion.

Requirements and limitations​

Before using Bulk Ingest, review the following constraints:

  • Targeted date only: The system supports data ingestion for a specific, targeted date — not days, weeks, or months of data in a single job.
  • 3-day window: You can only select files from within the previous 3 days.
  • Maximum 20 files per job: Each Bulk Ingest job can process a maximum of 20 .gz audit files. For initial testing, use a single file.
  • One concurrent job: The system runs one Bulk Ingest job at a time. Additional jobs are queued.
  • Lower priority than live audit data: Active audit data processing always takes precedence over Bulk Ingest. There is no way to predict how long a Bulk Ingest job will take.
  • No standard support: Bulk Ingest is a background task and is not covered under the standard support contract.
  • Schedule during off-peak hours: Run Bulk Ingest jobs during low-activity periods to minimize impact on active audit processing.

NFS setup — required before first use​

Bulk Ingest requires NFS ingestion to be configured on your ECA cluster before the feature can be used. This is a one-time setup.

Step 1 — Create the Bulk Ingest directory on ECA nodes​

ecactl cluster exec "sudo mkdir -p /opt/superna/mnt/bulkingestion/<cluster-guid>/<cluster-name>"

Replace <cluster-guid> with your PowerScale cluster's GUID and <cluster-name> with its name. Skip this step if the directory already exists.

Step 2 — Configure a non-default bulk ingest path (if required)​

If you are using a non-default path for .gz audit log files, configure it via the Eyeglass CLI:

igls config settings set --tag=bulkingestpath --value=<PATH>

Replace <PATH> with the full directory path on PowerScale where audit logs are stored.

When using a non-default path, organize files in this structure:

/PATH/node-name/protocol/

Each node must have its own subdirectory containing a protocol folder for its .gz files.

Step 3 — Create an NFS export on PowerScale (non-default path only)​

Skip this step if the NFS export already exists for the default path.

isi nfs exports create <PATH> \
  --root-clients="<eca-ips>" \
  --clients="<eca-ips>" \
  --read-only=true \
  -f \
  --description "Bulk ingest export" \
  --all-dirs true

Replace <PATH> with your custom path and <eca-ips> with a comma-separated list of all ECA node IP addresses.

Step 4 — Edit the auto NFS configuration on each ECA node​

On each ECA node, edit /opt/superna/eca/data/audit-nfs/auto.nfs and add:

/opt/superna/mnt/bulkingestion/<cluster-guid>/<cluster-name> --fstype=nfs,nfsvers=4,ro,soft <FQDN>:<PATH>
  • For the default path, replace <PATH> with /ifs/.ifsvar/audit/logs.
  • For a non-default path, use the custom path from Step 2.
  • Replace <cluster-guid>, <cluster-name>, and <FQDN> with your cluster details.

Step 5 — Apply configuration and restart services​

ecactl cluster push-config
ecactl cluster exec "sudo systemctl restart autofs"

Step 6 — Mount the NFS export​

ecactl cluster exec "sudo /opt/superna/eca/scripts/manual-mount.sh"

Alternatively, restart the ECA cluster to trigger automatic mounting.

Step 7 — Verify the setup​

Test Bulk Ingest through the Eyeglass UI to confirm the NFS mount is working and files are visible.

Running a Bulk Ingest job​

Once NFS setup is complete:

  1. In the Cluster dropdown, select the PowerScale cluster whose backup audit files you want to ingest.

  2. Set the Start Date — the date for which you want to load audit files.

  3. Set the Search Previous window — how many days before the start date to search for available backup files (for example: 3 Days).

  4. Click Load Files. The system searches the ECA for backup audit log files matching your criteria and displays them in the Audit Files list.

  5. Review the files and select those you want to ingest.

  6. Confirm to start the job. Track the job status in the Jobs section of the left sidebar. Once ingestion is complete, the audit data is available in the Queries & Reports tab.

Note: Bulk Ingest is supported for PowerScale (Isilon) clusters only.

warning

Make sure the following line is present in the volumes section for spark-worker in docker-compose.yml on the ECA nodes:

- /opt/superna/mnt/bulkingestion:/opt/superna/mnt/bulkingestion:shared

If the line is missing, add it and restart the container:

ecactl cluster exec ecactl cluster services restart --container spark-worker

Bulk Ingest from the CLI (releases earlier than 2.5.11)​

On releases earlier than 2.5.11, ingest audit files manually by listing the audit files on PowerScale and submitting them from the Eyeglass CLI.

  1. SSH to the PowerScale cluster you want to re-ingest audit logs from.

  2. Go to the directory containing the audit logs. It is at the bottom of the following path, where the node directory varies by cluster (this example uses node008):

    cd /ifs/.ifsvar/audit/logs/node008/protocol

  3. List the contents to determine which audit files, by date and time, to re-ingest. The audit logs are .gz files.

    ls -lT

  4. Every cluster node has .gz files for the date you are ingesting, and the files from all nodes must be ingested. Repeat the previous steps for each node folder and note the file names for each node.

  5. Submit the .gz files in groups of 20 files at a time. Multiple files can be queued for ingestion, but only one is ingested at a time.

  6. SSH to the Eyeglass CLI as admin and create the ingestion file:

    cd /opt/superna/sca/data/bulkingest
    touch bulkingest.json
    vim bulkingest.json

  7. Paste the following content, substituting your own cluster name, cluster GUID, node IDs, and file names. To ingest from multiple nodes, add one object to the node array for each node.

    [{
     "cluster_name": "YOUR_PowerScale_CLUSTER_NAME",
     "cluster_guid": "YOUR_PowerScale_CLUSTER_GUID",
     "node": [{
         "node_id": "node008",
         "audit_files": ["node_audit_file.gz", "node_audit_file.gz"]
       },
       {
         "node_id": "node003",
         "audit_files": ["node_audit_file.gz", "node_audit_file.gz", "node_audit_file.gz", "node_audit_file.gz"]
       }
     ]
    }]

  8. Save the file, then run it using the absolute path to the file (the file can be located anywhere):

    igls rswsignals bulkLoadTAEvents --file=/opt/superna/sca/data/bulkingest/bulkingest.json

Depending on how large a period of time is being ingested, ingestion can take some time to complete.

Monitoring Bulk Ingest progress​

Each PowerScale node holds historical audit data, and each compressed file is 1 GB in size. Each node can have multiple files to ingest for a given day, and the higher the audit rate, the more .gz files need to be ingested. Ingesting multiple days of historical audit data can be slow.

  1. Start the queue monitor. Log in to node 1 of the ECA cluster and run:

    ecactl containers up -d kafkahq

  2. Open the Jobs icon running jobs view to verify that the bulk ingestion job is running. Each CLI command starts an audit job to process the files in the JSON configuration file. Wait for the job to finish before submitting more files. The Wait for Spark Job step shows a spinning symbol while it is in progress and a blue checkmark when the job has finished processing.

  3. To view event ingestion progress, browse to http://x.x.x.x/kafkahq, where x.x.x.x is the IP address of node 1 of the ECA cluster, and log in as ecaadmin.

  4. Open Topics and select the bulkingestion topic, which tracks the current progress of the ingestion task:

    • Lag — Goes up or down depending on the ingestion speed. A value of 0 means the ingestion job is finished and no more file events are being processed for the current active job. Check the running Jobs view to verify that the active job shows finished. Any queued jobs start automatically.
    • Count — Always increases as new events are processed from all jobs. When you add more JSON files to the queue, this value increases as events are ingested.

Common audit use cases​

Use the following tools to address typical audit requirements.

Urgent request to react to a security event​

A data leak, user termination, or information delete request needs answers fast, and it is not always clear what to look for across multiple folders. Use WireTap to see all file activity by user and path as it happens. WireTap supports advanced filtering of specific events, I/O by a single user, or even a file name, and it streams live audit data to the GUI, so it avoids searching the database and speeds up the investigation.

User reports of missing files in a share path​

  • Use Where Did My Folder Go? to search a path such as /ifs for directory renames (moves) and deletes with a single click, and see whether deletes or renames are the root cause. It is a purpose-built index for this common issue.
  • Create a query with the cluster and path to monitor, save it, and schedule it to run every hour to alert you to any deletes in that path. Add a file extension to narrow the delete query.
  • Create a WireTap session on the path to monitor it in real time if deletes recur and it is not known who is deleting the files. If it is a specific user issue, WireTap the user while they repeat the sequence that reproduces the problem.

Application performance issue on a NAS share or export​

Performance problems can be caused by file locking, temp file creation on the NAS share instead of local disk, or a poor application workflow accessing network shares and exports. Create a WireTap session for the affected user or path and monitor it while end users repeat the application operations. Use a path-based WireTap when multiple users report a performance issue on a share, and a user-based WireTap when a single user is affected.

Compliance reporting​

Regulations such as HIPAA and PCI require that an in-scope device can report on user access to data, so you know who has access to data for traceability. The built-in Stale User Access report shows which users accessed data they have permission to see over a time period. Users who do not access data can be considered for removal, following the least-access security best practice. The built-in User Access report lists the users who can mount SMB shares, with user groups expanded at the SMB level to build a full user list for a share, which you can send to departments to verify data access privileges.

Excessive permissions analysis​

The Excessive Permissions report identifies users with access to data that is no longer being accessed. It analyzes the users who have accessed shares, resolves their share access from AD group membership, and lists the users who have access to shares but no actual file activity within the report range. These users are candidates for reduced group membership, which narrows access to data. Open the report from the report list.

User behavior audit​

Random user audits and suspicious file access auditing are common security requirements.

  • Create a WireTap session for a single user and monitor it actively.
  • Build a query based on a user ID and a date range to return all file access on all shares within the date range.

Network-aware monitoring with Active Auditor triggers​

Active Auditor triggers provide pre-built logic and custom rules for proactive monitoring. See Active Auditor to configure them.

  • Data Loss Prevention monitors users doing a bulk copy of sensitive data. Use it on a subset of your data, such as financial or other sensitive data, and configure the trigger with the percentage of the data on the path that represents normal usage, for example 5-10%. Experiment with the percentage to avoid false positives.
  • Mass Delete monitors paths for high-rate deletes by users, to give visibility into deletes and user behaviors. Review the triggers to find users with unusual workflows that are affecting the cluster with high-rate deletes and copies.
  • Custom triggers create rules with AND/OR logic using audit data fields, thresholds, and time windows. Examples:
    • Subnet-aware access: Monitor a path based on the source IP subnet of the hosts touching the data. Use this when application servers on a subnet are the only authorized machines to access the data, to identify any user trying to access the data directly.
    • Banned file types: Use a simple extension-based trigger, for example mp3, to locate users touching, creating, or accessing banned file types.
    • User-based deletes: If a user is suspected of deleting data in a group share, configure a user trigger for deletes to get a notification any time the user deletes data.
    • External access: Monitor all access to centralized storage from VPN or Wi-Fi with a subnet-aware policy, to identify who is accessing what from external subnets.

Planning and operations​

Daily operating procedures​

  • Monitor alarms daily and act on them. Some alarms indicate network connection problems to managed clusters, and not acting on them results in missed audit data ingestion. If audit data is missing because of network issues, re-ingest it — see Bulk Ingest tab. Bulk Ingest is a slow background process.
  • Configure and monitor Robo Audit so you can verify normal audit data ingestion and storage in the database. It also tests searching daily. See Health Check — Robo Audit.

Deployment topology and query performance​

  • Centralize the ECA cluster when possible and use the WAN link to send audit events. Audit data is XML over NFS and tolerates latency well. Planning decisions for one ECA cluster serving one or more clusters include the number of clusters assigned to it, the number of audit events per second (the number of active SMB or NFS connections is used to size the event rate), the WAN link speed, and query performance.

  • Two key factors for the audit analytics database are write performance for storing audit event streams and read performance for queries.

  • Increasing the ECA cluster size to 6, 9, or 12 VMs increases event rate processing and analysis job report speed. For an event rate of 10,000 or more events per second in total across the ECA cluster, use a 6, 9, or 12 VM ECA cluster. To measure the rate, run the following command on the PowerScale cluster and send the results to Support:

    isi statistics query current --nodes=all --stats=node.disk.xfers.rate.sum

    Nodes 2 to 12 only run containers for reading and writing data and analysis, so their memory can be lowered. Contact Support for assistance.

Reduce the load on PowerScale by disabling audit events​

PowerScale can disable some audit event types to reduce the audit workload. Open a support case to get a recommendation on which events can be disabled.

  • On OneFS 8.2 and later, each audit event can be enabled or disabled. Use isi audit settings modify --help to list the options. The --audit-success option, together with --clear-audit-success, --add-audit-success, and --remove-audit-success, accepts: close, close_directory, close_file, close_file_modified, close_file_unmodified, create, create_directory, create_file, delete, delete_directory, delete_file, get_security, get_security_directory, get_security_file, logoff, logon, open, open_directory, open_file, open_file_noaccess, open_file_read, open_file_write, read, read_file, rename, rename_directory, rename_file, set_security, set_security_directory, set_security_file, tree_connect, write, write_file, and all.
  • Earlier OneFS releases offer less control. Use isi audit settings modify --help; --add-audit-success accepts close, create, delete, get_security, logoff, logon, read, rename, set_security, tree_connect, write, and all.

To list the audit settings for an access zone, run isi audit settings view --zone=<zone-name>. The default is create, delete, rename, set_security, and close for both Audit Failure and Audit Success.

Centralize CSV reports on a NAS export​

To store a second copy of saved CSV reports centrally, mount an NFS export from PowerScale on the Eyeglass appliance:

  1. Create an NFS export on PowerScale that is secured to all ECA node IP addresses and has write access.

  2. On the Eyeglass appliance, create a directory for the reports and set its ownership and permissions:

    mkdir /opt/superna/sca/data/EA_reports
    chown sca:users /opt/superna/sca/data/EA_reports
    chmod 755 /opt/superna/sca/data/EA_reports

  3. Set the report archive path, then verify it:

    igls admin eaCsvArchivePath set --value=/opt/superna/sca/data/EA_reports
    igls admin eaCsvArchivePath

  4. Mount the export on that path. Run sudo -s, enter the admin password, and run yast. Select Network Services → NFS client, add a mount, and enter the FQDN of the remote host and the local path created above.

Debug logs for searches​

The debug logs for each search are stored in HDFS and can be viewed from the Spark history server web UI. Open Health Check → Manage Services, expand node 1, and locate the Spark history URL.

Who audits the auditor?​

The Eyeglass appliance logs its own login activity and major UI actions — including actions taken within Data Auditing itself — independent of the PowerScale audit stream Data Auditing queries. This appliance-level audit log is stored on the file system and is included in Eyeglass appliance backup ZIP files. See Appliance Hardening Guide — WebUI Security API Auditing for how to review it (apiaudit.log, correlating actions to a user and source IP via the web server access log).

Tested limits​

The following limits were tested for Data Auditing. They are tested values, not hard stops; larger environments may work but have not been validated.

FunctionTested limitComments
Built-in Access report for users with access to a specific SMB share100,000 (any combination of users and AD groups)Tested with an Active Directory of 40,000 users and SMB share-level permissions. A larger directory may work without issues.
Concurrent quick searches10
Concurrent reports1Additional report jobs are queued until a report slot is available on the ECA cluster.
Enterprise Compliance Mode clustersSupportedRequires the compadmin user to add the cluster to Eyeglass. See Compliance Mode.
Concurrent active WireTap monitoring sessions2Rate limits apply to the event rate displayed in the UI.
Defined WireTap configurations (user or path)2Rate limits apply to the event rate displayed in the UI.
Active Auditor mass delete policies2RAM and CPU may need to be increased to support the policies.
Active Auditor DLP policies2RAM and CPU may need to be increased to support the policies.
Custom Active Auditor triggers25Tested limit of concurrent triggers.
Records returned from a query1,000,000
Longest-running single search job20 hoursJobs that consume search resources are capped at 20 hours so that one long search cannot consume too many resources.

Best practices​

  • Use specific paths and short time ranges. The audit database can contain billions of events. Broad queries against top-level paths with multi-week ranges produce unmanageably large results and slow query times significantly.
  • Save queries you run regularly. Any query run more than once — weekly access reports, monthly deletion summaries, compliance checks — should be saved and scheduled for consistency.
  • Use WireTap to verify audit pipeline health. If you suspect events are not flowing from a cluster, start a WireTap against a known-active path. No events on a busy path is a signal that the ECA or the cluster's audit configuration needs attention.
  • Run Bulk Ingest before forensic investigations. If you are investigating an event that occurred before your ECA's continuous coverage began, run Bulk Ingest first to make the relevant data available.
  • Treat the 50,000 record default as a ceiling, not a target. If a query consistently returns the maximum, the filters are not specific enough — narrow the user, path, or time range before raising the limit.
Known limitation: case mismatch on SMB subfolder mounts

PowerScale is a case-sensitive file system, but Windows is not. If a client mounts an SMB share at a subfolder path whose case doesn't match the file system exactly (for example, mounting \\cluster\share\TEMP when the actual path on disk is /ifs/data/temp), the resulting audit events are recorded against the mismatched-case path rather than the real one — which can make those events hard to find with an exact-path search. This does not occur if the share itself is mounted (without a subfolder) or if the subfolder's case matches the file system, and NFS is not affected, since NFS denies mounts with mismatched case. There is no PowerScale fix planned for this. If you suspect mismatched-case mounts exist in your environment, start searches from the share's root path rather than a specific subfolder path. The same applies when a user renames a path below an SMB share: audit data already saved in the database keeps the old path case, so a search on the current path finds no records. Always begin a search at the base path of the SMB share so that all records are located, even if users change folder or file names under the share path.

See also​

  • Threat Detections — Use Data Auditing queries to supplement investigation of active security events.
  • Active Auditor — Configure policy-based triggers that generate events on the Threat Detections page.
  • Health Check — Robo Audit — Continuous automated SMB activity tracking with scheduled reports.
  • SQL DB Retention Management — Configure archival thresholds, compression, and cold-storage paths for the underlying audit database, and back up or restore it directly.
  • Audit Event Forwarding — Forward the raw PowerScale audit event stream to an external syslog server, or archive it to S3 via Data Orchestration.