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.]

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