This component is particularly relevant for organizations that run mixed environments where OpenText eDirectory serves as the LDAP directory service alongside or instead of Microsoft Active Directory, and where OpenText OES servers host NSS file system volumes containing business-critical or sensitive data.

OpenText eDirectory:

OpenText eDirectory is an enterprise-grade LDAP directory service used by many organizations — particularly those with legacy NetWare infrastructure or those in education, government, and healthcare sectors — to manage user identities, authentication, and access control. eDirectory auditing captures changes and access events within the directory, including:

• User account creation, modification, and deletion
• Object creation, modification, deletion, and renaming
• Group membership and security equivalence changes
• Password changes
• LDAP authentication events
• Attribute value changes across directory objects

OpenText OES NSS (NetWare Storage Services):

OES NSS is the high-performance file system used on OpenText Open Enterprise Server (OES) Linux servers. NSS volumes are commonly used as enterprise file storage in organizations running OES infrastructure. NSS auditing captures file system activity on these volumes, including:

• File and folder reads, writes, and deletions
• File and folder creation and renaming
• Permission and trustee assignment changes
• Volume-level activity

How eDirectory & NSS Auditing works:

LT Auditor ^MP via syslog directly from the OpenText systems themselves. LT Auditor ^MP listens for incoming syslog streams on dedicated ports and processes the data through transformation rules configured in the platform.

Default port assignments:

These ports can be changed in the LT Auditor ^MP console under Configure → Transformation Rules if they conflict with other services in your environment.

Data flow:

1. eDirectory and OES NSS servers are configured to forward audit events via syslog to the LT Auditor ^MP server
2. LT Auditor ^MP receives the syslog streams on the configured ports
3. Transformation rules normalize the incoming data into structured audit records
4. Processed events are stored in the LT Auditor ^MP database and become available in the dashboard, View module, alerts, and reports

Key capabilities include:

• Real-time collection of eDirectory object and attribute change events
• Monitoring of LDAP authentication activity across eDirectory servers
• Collection of NSS file system activity from OES Linux servers
• Support for UDP, TCP, and TLS syslog transport protocols
• Configurable transformation rules for normalizing incoming log data
• Integration with LT Auditor ^MP alerting, reporting, and compliance frameworks
• Support for compliance reporting under HIPAA, GDPR, NIS2, ISO 27001, and other frameworks

Common use cases:

• Monitoring unauthorized modifications to eDirectory objects and attributes
• Tracking privileged account changes in eDirectory environments
• Auditing file access and modification on NSS volumes hosting sensitive data
• Detecting suspicious authentication patterns in eDirectory
• Producing compliance evidence for HIPAA, GDPR, and other frameworks in OpenText environments
• Bridging the gap between OpenText and Windows/cloud monitoring in mixed environments

How eDirectory & NSS Auditing fits into LT Auditor ^MP:

eDirectory & NSS Auditing extends LT Auditor ^MP ‘s coverage into OpenText infrastructure, ensuring that organizations running mixed environments have the same level of visibility across their OpenText systems as they do across Windows, Linux, and cloud environments. Events collected from eDirectory and NSS appear in the same dashboards, alert rules, and compliance reports as data from all other modules.

[Your administrator should confirm which eDirectory servers and OES NSS volumes are in scope for monitoring in your environment, and identify the appropriate person to configure the syslog forwarding settings on the OpenText systems themselves.]

Azure Log Connector replaces and significantly expands on the previous EntraConnector module. Where EntraConnector focused primarily on Entra ID identity events, Azure Log Connector extends coverage to include Microsoft 365 collaboration activity — including SharePoint Online and OneDrive — giving organizations a much more complete picture of their cloud environment.

What Azure Log Connector collects:

Azure Log Connector collects the following categories of cloud audit activity:

How Azure Log Connector works:

Azure Log Connector is installed as a Windows service on a server in your environment. It connects to Microsoft Azure and Microsoft 365 using a registered App Registration in Microsoft Entra ID, polls for new audit log entries on a configurable interval, and forwards collected events to the LT Auditor ^MP server via syslog.

Data flow:

1. Azure Log Connector authenticates to Microsoft Graph and the Office 365 Management APIs using the configured App Registration credentials
2. The collector polls for new events across all enabled log categories at the configured interval (default: every 5 minutes)
3. Collected events are forwarded to the LT Auditor ^MP server via syslog on the configured port (default: 5050)
4. Events are processed by LT Auditor ^MP transformation rules and stored in the database
5. Collected data becomes available in the LT Auditor ^MP dashboard, View module, alert rules, and compliance reports

Key capabilities include:

• Collection of sign-in, audit, and identity protection logs from Microsoft Entra ID
• Collection of SharePoint Online and OneDrive activity logs from Microsoft 365
• Configurable polling intervals and batch sizes for efficient API usage
• Lookback capability on startup to recover events missed during downtime
• Support for UDP, TCP, and TLS syslog transport to LT Auditor ^MP
• Configurable per-category enable/disable via appsettings.json
• Raw API response logging for troubleshooting purposes
• Integration with LT Auditor ^MP alerting, reporting, and compliance frameworks

Common use cases:

• Monitoring privileged role assignments and administrative changes in Entra ID
• Detecting suspicious or risky sign-in activity across your Microsoft 365 tenant
• Auditing SharePoint Online and OneDrive file access and sharing for data governance
• Tracking conditional access policy changes that may affect your security posture
• Producing compliance evidence for GDPR, HIPAA, NIS2, ISO 27001, and other frameworks
• Gaining unified visibility across both on-premises and Microsoft cloud environments

How Azure Log Connector fits into LT Auditor ^MP:

Azure Log Connector acts as the Microsoft cloud data collection layer for LT Auditor ^MP. It works alongside other modules — EventLogCentral for Windows on-premises activity, PowerShell Orchestrator for Active Directory assessments, and PII Scanner for sensitive data discovery — to give LT Auditor ^MP comprehensive coverage across your entire environment, from on-premises infrastructure to the Microsoft cloud.

Prerequisites for Azure Log Connector:

• Windows Server 2019 or newer
• Internet connectivity to Microsoft Graph and Office 365 APIs
• Administrative access to the server
• Access to the Azure Portal with permissions to create App Registrations
• LT Auditor ^MP server installed and running
• Outbound network access to the LT Auditor ^MP syslog listener port

[Your administrator should confirm which Microsoft 365 services and Azure log categories are in scope for collection in your environment, and ensure the App Registration is created by someone with the appropriate privileges in your Azure tenant.]

When to run an on-demand scan:

Prerequisites:

Before running an on-demand scan confirm the following:

• At least one PII Scanner Agent is registered and showing as Online in the Clients page
• The intended agent has read access to the path you want to scan
• At least one target is configured in the Targets page
• The PII detection classes relevant to your scan are enabled in the PII Classes page

Creating an on-demand scan job:

1. Log in to the PII Scanner Server web interface at:

2. Navigate to Jobs
3. Click Add Job
4. Configure the job:

Job Name Use a name that clearly identifies this as an on-demand scan and captures its context:

Examples:

On-Demand — HR Share Audit Prep — June 2026

Incident Response Scan — FileServer01 — 2026-06-08

New Share Baseline — Finance Q2 2026

Client Select the agent that has access to the path you want to scan. Confirm the agent shows as Online in the dropdown.

Path to Scan Enter the full path to the directory or share to scan:

Windows:

\\fileserver01\departments\hr

C:\SensitiveData

Linux:

/mnt/shares/finance

/home/shared/legal

Include Extensions (optional) For a focused on-demand scan, limit to the most relevant file types to reduce scan time:

*.docx, *.xlsx, *.pdf, *.txt, *.csv

Leave blank for a comprehensive sweep of all file types — recommended for incident response scans.

PII Classes Select the PII detection classes to apply. For incident response or pre-audit scans consider enabling all available classes for maximum coverage.

Target Host Select your LT Auditor-MP server as the destination for scan results.

5. Click Queue Job

The job is submitted immediately with a status of Queued. The assigned agent will claim it on its next poll cycle and begin scanning.

Monitoring the scan:

1. Navigate to Jobs
2. Locate your job — the status updates from Queued to Running once the agent claims it
3. Review job progress:

4. Refresh the page periodically to see updated progress

For large directories scans can take significant time. PII matches are forwarded to LT Auditor-MP in real time as they are found — you do not need to wait for the scan to complete before reviewing results.

Viewing results as the scan runs:

Because PII matches are forwarded to LT Auditor-MP in real time you can begin reviewing results before the scan completes:

1. Log in to the LT Auditor-MP Web UI in a separate browser tab
2. Navigate to View
3. Select the PII Scanner environment and category
4. Set the date range to Today or Last Hour
5. Results populate as the agent finds and forwards matches
6. Click any result row to view full details:
   • File Path — where the PII was found
   • PII Class — the type of sensitive data matched
   • Timestamp — when the match was detected

Confirming scan completion:

1. Return to the PII Scanner Server web interface
2. Navigate to Jobs
3. Confirm the job status has updated to Succeeded
4. Note the Completed timestamp and Records Processed count for your records

If the job status shows Failed:

1. Review the result details in the job record for error information
   

Check the agent logs for more specific error details:

Linux:

cat /opt/bluelance/scanner/scanner.log

 Windows:

C:\Program Files\Blue Lance 2-0\LTA_PII_Scanner_Agent\logs\

3. Resolve the identified issue and create a new job to rerun the scan if needed
   

Documenting on-demand scan results:

For scans run in response to audits, incidents, or compliance queries, document the scan and its results:

1. Note the job name, scan path, date, time, assigned agent, and PII classes used
2. In LT Auditor-MP navigate to View and filter for the scan results
3. Export the results:
   • Click Export
   • Choose PDF for audit submission or CSV for detailed analysis
   • Click Download
4. Retain the export as evidence of the data discovery activity

[Your administrator should establish a standard process for documenting and retaining on-demand scan records, particularly those run in response to security incidents or compliance audits.]

Best practices:

• Always confirm the assigned agent is Online before creating a job — a job assigned to an Offline agent will remain Queued indefinitely
• For incident response scans leave the Include Extensions field blank and enable all PII classes for maximum coverage
• Use descriptive job names that capture the date, scope, and reason for the scan so the Jobs page serves as an auditable record
• Begin reviewing results in LT Auditor-MP as the scan runs rather than waiting for completion — this is especially important during incident response
• Export and retain scan results immediately after completion, particularly for incident response or audit-driven scans
• For recurring scans of the same path consider creating a schedule rather than repeatedly creating manual jobs

[Your administrator should document the on-demand scan process as part of your organization’s incident response and compliance procedures so it can be followed consistently by any team member.]

Understanding scan results:

Each result record forwarded to LT Auditor-MP represents a single PII match found in a scanned file. A single file may generate multiple result records if it contains multiple types of PII or multiple instances of the same PII type.

Each result record includes:

• File Path — the full path to the file where the match was found
• PII Class — the type of sensitive data detected
• Class Type — the category of the detected class (PII, PHI, Sensitive, Confidential, or Private)
• Timestamp — when the match was detected during the scan
• Agent — the client agent that performed the scan
• Job Name — the scan job that generated the result

Accessing scan results in LT Auditor-MP:

1. Log in to the LT Auditor-MP Web UI
2. Navigate to View in the main navigation menu
3. Select the view configured for PII Scanner data or create a new one:
   • Click Create View
   • Set the Environment to your PII Scanner environment
   • Set the Category to PII Scan Results
   • Set a default date range
   • Click Save
4. The log table populates with PII match records from your scans

Filtering scan results:

Filter by job name:

1. Click Advanced Filters
2. Add a condition:
   • Field — Job Name
   • Operator — Equals
   • Value — the name of the specific scan job
3. Click Apply Filters

Filter by PII class:

1. Click Advanced Filters
2. Add a condition:
   • Field — PII Class
   • Operator — Equals or Contains
   • Value — the class name to focus on (e.g., Social Security Number)
3. Click Apply Filters

Filter by class type:

1. Click Advanced Filters
2. Add a condition:
   • Field — Class Type
   • Operator — Equals
   • Value — PII, PHI, Sensitive, Confidential, or Private
3. Click Apply Filters

Filter by file path:

1. Click Advanced Filters
2. Add a condition:
   • Field — File Path
   • Operator — Starts With or Contains
   • Value — the directory path to focus on
3. Click Apply Filters

Filter by agent:

1. Click Advanced Filters
2. Add a condition:
   • Field — Agent
   • Operator — Equals
   • Value — the hostname of the agent that performed the scan
3. Click Apply Filters

Interpreting scan results:

When reviewing results focus on the following questions:

Is the sensitive data in an expected location? PII found in designated access-controlled directories is expected. PII found in unexpected locations — a public share, a developer’s working directory, or a temporary folder — requires immediate attention and remediation.

Is the class type appropriate for the location? PHI in a healthcare application directory may be expected. PHI in a general file share is not. Review whether the type of sensitive data found makes sense for the location it was discovered in.

How many files are affected? A single match in one file is very different from hundreds of matches across many files. Use grouping and aggregation in LT Auditor-MP reports to understand the scale of findings across a scan.

Viewing full result details:

1. Click on any result row in the log table
2. The detail panel opens and displays:
   • File Path — full path to the affected file
   • PII Class — the type of sensitive data detected
   • Class Type — PII, PHI, Sensitive, Confidential, or Private
   • Timestamp — when the match was detected
   • Agent — which client agent found the match
   • Job Name — which scan job generated the result
   • Raw Log — the original forwarded syslog record
3. Click Close to return to the results table

Identifying false positives:

Not every match represents a genuine sensitive data finding. Some regex patterns may produce false positives — matches that technically satisfy the pattern but do not represent real sensitive data. Use the file path and raw log context to validate whether a match represents actual sensitive data before acting on it.

If a PII class is consistently generating false positives:

1. Navigate to PII Classes in the PII Scanner Server web interface
2. Review and tighten the regex pattern for the relevant class
3. Consider disabling the class temporarily if the false positive rate is too high to manage

Acting on scan results:

When genuine sensitive data is found in an unexpected or unauthorized location:

1. Document the finding:

• Export the relevant results from LT Auditor-MP as PDF or CSV
• Note the file path, PII class, class type, scan date, and agent

2. Assess the risk:

• Determine who has access to the location where the sensitive data was found
• Review access logs in LT Auditor-MP to determine whether the file has been accessed recently
• Assess whether the finding represents a compliance violation that must be reported

3. Remediate:

• Work with the file owner or relevant department to relocate, encrypt, or delete the sensitive file
• Review and update access controls on the affected location
• Run a follow-up on-demand scan of the same path after remediation to confirm the sensitive data has been successfully addressed

4. Report:

• If the finding represents a compliance violation follow your organization’s incident response and breach notification procedures
• Retain scan results and remediation records as evidence for compliance audits

[Your administrator should define a standard remediation workflow for PII findings and ensure all team members know how to follow it.]

Generating PII scan reports in LT Auditor-MP:

For compliance documentation and management reporting, generate structured reports from PII scan results:

1. Navigate to Report in the LT Auditor-MP Web UI
2. Click Create Report
3. Configure the report:
   • Environment — PII Scanner environment
   • Category — PII Scan Results
   • Date Range — the period to cover
4. Under Columns include:
   • File Path
   • PII Class
   • Class Type
   • Timestamp
   • Agent
   • Job Name
5. Under Grouping consider grouping by:
   • PII Class — to see a breakdown of finding types
   • Class Type — to distinguish PII from PHI and other categories
   • File Path — to identify the most affected locations
6. Click Save and then Generate Report
7. Download the report as PDF for audit submission or CSV for detailed analysis

Setting up alerts for PII findings:

Configure LT Auditor-MP to alert your team when PII matches are detected during a scan:

1. Navigate to Manage in the LT Auditor-MP Web UI
2. Select the PII Scanner environment and category
3. Click Add Filter
4. Configure the filter:
   • Filter Name — e.g., PHI Finding Alert
   • Condition — Class Type Equals PHI
   • Action — Alert
   • Recipients — your security or compliance team email addresses
5. Click Save and set to Active

[Your administrator should configure alerts for each sensitive class type relevant to your compliance obligations — at minimum PHI for HIPAA environments and PII for GDPR environments.]

Best practices:

• Review scan results promptly after each scan completes — sensitive data findings should not sit unaddressed
• Use the Class Type filter to prioritize PHI and PII findings for immediate investigation before reviewing Sensitive and Confidential findings
• Validate matches using the file path and raw log context before acting — not every match is a genuine sensitive data finding
• Export and retain scan results as part of your compliance evidence library
• Run a follow-up on-demand scan after remediation to confirm sensitive data has been successfully removed from the affected location
• Track remediation progress for all findings to demonstrate to auditors that your organization acts on data discovery results
• Set up alert rules in LT Auditor-MP for PHI and PII class type findings so your team is notified promptly rather than discovering findings during a scheduled review

[Your administrator should establish a regular cadence for reviewing accumulated scan results in LT Auditor-MP as part of an ongoing data governance review process.]

How PII Scanner works:

The server manages all aspects of the scanning program — clients, scan jobs, PII detection rules, target destinations, and scheduled jobs. Agents register with the server, poll for queued scan jobs, scan local or network file paths for sensitive data patterns, and forward results to a configured destination such as an LT Auditor-MP server.

Data flow:

1. Administrator defines PII detection classes and configures target destinations in the server web UI
2. Administrator creates a scan job or schedule, assigning it to a registered agent
3. The agent polls the server and claims the queued job
4. The agent scans the specified file path using the selected PII detection patterns
5. Detected PII matches are forwarded in real time to the configured target (LT Auditor-MP)
6. The agent reports job completion back to the server
7. Results are available in LT Auditor-MP for review, alerting, and compliance reporting

Core components:

PII Scanner Server An ASP.NET Core 8 web application that hosts the administrative interface and REST API. It manages client registrations, scan jobs, PII class definitions, target destinations, and scheduled jobs. The server runs as a Windows Service or Linux systemd service and uses a SQLite database for persistence. The web interface is accessible via browser on port 52766 (HTTPS) or 52765 (HTTP).

PII Scanner Agent A Python-based scanning agent deployed on machines whose file systems you want to scan. The agent registers with the PII Scanner Server, polls for available jobs at a configurable interval, executes scans against specified file paths, and forwards detected PII matches to the configured target destination in real time.

Key capabilities include:

• Detection of PII, PHI, and other sensitive data types using configurable regex-based patterns
• Support for scanning Windows and Linux file systems and network shares
• Centralized scan job management through a web-based administrative interface
• On-demand and scheduled recurring scan jobs
• Real-time forwarding of scan results to LT Auditor-MP via UDP, TCP, or TLS syslog
• Support for multiple simultaneous scanning agents across large environments
• Configurable file extension filtering per scan job
• Runs as a Windows Service or Linux systemd service

Supported PII and sensitive data class types:

• PII — Personally Identifiable Information
• PHI — Protected Health Information
• Sensitive
• Confidential
• Private

Common use cases:

• Identifying where sensitive data lives across your file systems
• Detecting PII or PHI in unexpected or unauthorized locations
• Supporting GDPR, HIPAA, PCI-DSS, and NIS2 compliance requirements
• Producing evidence of data discovery efforts for auditors
• Automating recurring data discovery across high-risk directories

How PII Scanner fits into LT Auditor-MP:

PII Scanner extends LT Auditor-MP’s capabilities into proactive data discovery. While other modules like EventLogCentral and Azure Log Connector monitor activity as it happens, PII Scanner actively interrogates file systems to find where sensitive data exists — giving organizations the visibility needed to make informed decisions about access controls, data governance, and compliance obligations.

[Your administrator should confirm which file systems and data types are in scope for scanning in your environment, and ensure scanning activity complies with any applicable data privacy policies.]

Supported frameworks include:

• HIPAA
• NIST 171
• GDPR
• NIS2
• ISO 27001
• DORA
• FFIEC
• FDIC
• PCI-DSS

Setting up a compliance framework:

1. Navigate to Compliance in the Web UI
2. Click Add Compliance Framework
3. Configure the framework details:
   • Name — the framework name (e.g., “GDPR Compliance”)
   • Description — purpose and scope
   • Reference Code — the standard identifier (e.g., “GDPR-2016/679”)
   • Category — industry or regulation type
   • Priority — Critical, High, Medium, or Low
4. Click Save

Creating compliance rules within a framework:

Compliance rules define the specific requirements within a framework and how the system monitors them.

1. Select the compliance framework you just created
2. Click Add Rule
3. Configure the rule details:
   • Rule Name — the specific requirement (e.g., “Access Logging Required”)
   • Description — a detailed explanation of the requirement
   • Reference — the section or clause number from the framework
   • Severity — the impact level if the rule is violated
4. Link the rule to audit data:
   • Environment — which environment this applies to
   • Category — which log category to monitor
   • Operations — which specific operations must be logged
5. Define compliance criteria:
   • Must Exist — certain events must be present in the audit data
   • Must Not Exist — certain events must never occur
   • Count Thresholds — minimum or maximum event counts
   • Time Constraints — events must occur within defined timeframes
6. Click Save

Linking reports to compliance rules:

Associating reports with compliance rules automates evidence collection for audits.

1. Open the compliance rule configuration
2. Navigate to the Linked Reports tab
3. Click Link Report
4. Select the reports that provide evidence of compliance for this rule
5. Click Save

Generating compliance reports on demand:

1. Navigate to Compliance → Reports
2. Select the compliance framework
3. Choose the time period to cover
4. Select which rules to include:
   • All Rules
   • Non-Compliant Rules Only
   • Critical Rules
   • Custom Selection
5. Click Generate Report
6. Download the report in your preferred format:
   • PDF — for auditor submission
   • Excel — for detailed internal analysis
   • CSV — for data processing

Scheduling compliance reports:

1. Navigate to Compliance → Scheduled Reports
2. Click Add Schedule
3. Configure the schedule:
   • Framework — which framework to report on
   • Frequency — Weekly, Monthly, Quarterly, or Annually
   • Recipients — email addresses for report delivery
   • Format — PDF, Excel, or CSV
4. Click Save

Monitoring compliance status:

1. Navigate to the Compliance Dashboard
2. Review key metrics:
   • Overall Compliance Score — percentage of rules currently met
   • Compliant Rules — rules currently satisfied
   • Non-Compliant Rules — rules with active violations
   • Pending Rules — rules awaiting validation
3. Click into any framework to drill down into individual rule status
4. Click a specific rule to view violation details, last evaluation time, and supporting evidence

Configuring compliance alerts:

Set up notifications so your team is informed immediately when a compliance violation is detected.

1. Open a compliance rule
2. Navigate to the Alerts tab
3. Click Add Alert
4. Configure:
   • Trigger Condition — when to send the alert
   • Recipients — email addresses or user groups
   • Alert Frequency — Immediate, Daily, or Weekly
   • Escalation — who to notify if the violation is not resolved
5. Click Save

Best practices:

• Group related rules logically within each framework for easier navigation
• Always link reports to compliance rules to automate evidence collection
• Define clear, measurable criteria for each rule so compliance status is unambiguous
• Schedule reports in advance of known audit periods
• Regularly review rules to ensure they reflect current regulatory requirements
• Restrict compliance configuration access to authorized personnel only
• Document remediation actions taken when violations are detected