When to run a verification check:

Step 1 — Verify the LT Auditor ^MP transformation rules are active:

Before checking the OpenText systems, confirm that LT Auditor ^MP is ready to receive data on the correct ports.

1. Log in to the LT Auditor ^MP Web UI
2. Navigate to Configure
3. Locate the eDirectory transformation rule (default port 5014) and the NSS transformation rule (default port 5015)
4. Confirm both rules show a status of Active
5. If either rule is inactive, click the three vertical action buttons and select Enable

Step 2 — Verify firewall connectivity from OpenText servers:

Confirm that each eDirectory and OES server can reach the LT Auditor ^MP server on the configured syslog ports.

Run the following from each OpenText server:

For eDirectory servers (port 5014):

nc -zv <LT_AuditorMP_Host> 5014

For OES NSS servers (port 5015):

nc -zv <LT_AuditorMP_Host> 5015

A successful response confirms connectivity is open. If the connection fails:

• Review firewall rules between the OpenText server and the LT Auditor ^MP server
• Confirm the LT Auditor ^MP server is running and the transformation rules are active
• Confirm the correct IP address is being used

Step 3 — Verify the eDirectory CEF audit daemon is running:

On each eDirectory server, confirm the CEF audit daemon is loaded and active:

ndstrace –c “modules” | grep cefauditds

The output should show cefauditds as a loaded module. If it does not appear:

Manually load the daemon:

ndstrace –c “load cefauditds”

Confirm it loads successfully, then check again:

ndstrace –c “modules” | grep cefauditds

Also confirm the audit configuration file is correctly set up:

cat /etc/opt/novell/eDirectory/conf/auditlogconfig.properties

Verify the host, port, and protocol values match your LT Auditor ^MP transformation rule settings.

Step 4 — Verify the NSS Audit Agent service is running:

On each OES server, confirm the ltaudit service is running:

systemctl status ltaudit.service

The service should show as active (running). If it is stopped or failed:

systemctl start ltaudit.service

systemctl status ltaudit.service

Confirm the service returns to active (running) before proceeding.

Step 5 — Check the NSS audit status log:

On each OES server, confirm the NSS Audit Agent has successfully connected to the NSS audit subsystem:

cat /opt/bluelance/log/nssstatus.log

Confirm the log contains:

Successfully opened live vigil file

If this message is not present:

• The agent may not have access to the NSS audit subsystem
• NSS may not be running or volumes may not be mounted

Review the general application logs for more detail:
ls /opt/bluelance/logs/

Step 6 — Check the syslog forwarding log:

On each OES server, confirm that events are being successfully forwarded to LT Auditor ^MP:

cat /opt/bluelance/log/syslog_send.log

Look for:

• Successful forwarding messages confirming events are reaching the LT Auditor ^MP server
• Any connection errors, timeout messages, or TLS certificate errors that may indicate a forwarding problem

If forwarding errors are present:

• Confirm network connectivity using the nc test in Step 2
• Confirm the port and protocol in the agent configuration match the LT Auditor ^MP transformation rule
• If using TLS, confirm certificate configuration is correct on both ends

Step 7 — Generate test events on OpenText systems:

To confirm the full end-to-end pipeline is working, generate known test events on your OpenText systems and verify they appear in LT Auditor ^MP.

Generating a test eDirectory event:

Perform a simple directory operation that eDirectory auditing is configured to capture — for example, modify an attribute on a test user object in iManager or via an LDAP command:

ldapmodify -H ldap://<eDirectory_Host> -D “<admin_DN>” -W <<EOF

dn: cn=testuser,ou=users,o=yourorg

changetype: modify

replace: description

description: Audit verification test

EOF

Generating a test NSS file event:

Perform a simple file operation on an NSS volume on the OES server — for example, create and then delete a test file:

touch /media/nss/<VolumeName>/audit_verification_test.txt

rm /media/nss/<VolumeName>/audit_verification_test.txt

Replace <VolumeName> with the name of an NSS volume on the server.

[Your administrator should confirm the correct NSS volume mount path used in your environment.]

Step 8 — Verify test events appear in LT Auditor ^MP:

After generating test events, confirm they appear in LT Auditor ^MP:

1. Log in to the LT Auditor ^MP Web UI
2. Navigate to View
3. Select the relevant environment and category:
   • For eDirectory events: eDirectory environment → Object Events or Attribute Events category
   • For NSS events: NSS environment → File Activity category
4. Set the date range to Last 15 minutes
5. Look for the test events you just generated
6. Click on a test event row to view full details and confirm the event data is correctly structured and normalized

If test events do not appear within a few minutes:

• Confirm the relevant daemon or service is running (Steps 3 and 4)
  
• Confirm firewall connectivity is open (Step 2)
  
• Confirm the transformation rule is active (Step 1)
  
• Review the syslog forwarding log for errors (Step 6)
  

Check the LT Auditor ^MP server logs for any ingestion errors:

On Linux:

cd /opt/bluelance/lcollector/logs/general/

 On Windows:

\Program Files\Blue Lance 2-0\Collector\Logs\General\

Step 9 — Confirm all servers are represented as sources:

After verifying individual servers, confirm that all configured eDirectory and OES servers are appearing as active sources in LT Auditor ^MP:

1. Navigate to View in the LT Auditor ^MP Web UI
2. Select the eDirectory or NSS environment
3. Set the date range to cover the last 24 hours
4. Filter by Source or Host and review the list of servers generating events
5. Cross-reference against your list of configured servers
6. If any server is missing from the source list:
   • Confirm the CEF audit daemon or ltaudit service is running on that server
   • Confirm syslog forwarding is configured correctly on that server
   • Revisit the relevant configuration article for that server type

[Your administrator should maintain a reference list of all eDirectory and OES servers that should be appearing as sources in LT Auditor ^MP, and use it during routine verification checks to quickly identify any gaps.]

Routine verification schedule:

Rather than verifying collection only after problems occur, incorporate collection verification into your regular operational routine:

[Your administrator should assign ownership of routine verification checks to a specific team member and document the results so the verification history is available for compliance audits.]

Common issues and resolutions:

Best practices:

• Run the full end-to-end verification workflow immediately after initial installation — do not assume the deployment is working without confirming test events appear in LT Auditor ^MP
• Incorporate routine verification checks into your regular operational schedule rather than waiting for problems to be reported
• Maintain a reference list of all configured eDirectory and OES servers and use it during verification to quickly identify any gaps
• Generate and retain verification records as evidence of your audit program’s ongoing effectiveness for compliance audits
• Address any identified collection gaps promptly — unmonitored servers represent both a security monitoring gap and a potential compliance violation
• Include collection verification in your change management process for any changes to OpenText systems, network infrastructure, or the LT Auditor ^MP server

[Your administrator should document the results of each verification cycle and retain them as part of your organization’s compliance evidence library.]

Understanding receiver settings:

LT Auditor ^MP uses Transformation Rules to define how incoming syslog data is received and processed. Each transformation rule specifies:

• The IP address the LT Auditor ^MP server listens on for incoming connections
• The port number the rule listens on
• The communication protocol — UDP, TCP, or TLS
• How the incoming log data is parsed and normalized into structured audit records

Two transformation rules are pre-configured for eDirectory and NSS auditing:

If these default ports conflict with other services in your environment, they can be changed in the transformation rule configuration.

Accessing transformation rules:

1. Log in to the LT Auditor ^MP Web UI
2. Navigate to Configure in the main navigation menu
3. Locate the relevant transformation rule in the list:
   • The eDirectory rule (default port 5014)
   • The NSS rule (default port 5015)
4. Click the three vertical action buttons to the right of the rule
5. Select Edit to open the transformation rule configuration window

Reviewing and updating receiver settings:

Once the transformation rule configuration window is open:

1. Navigate to the Settings tab
2. Review and update the following fields as needed:

IP Address: The network interface on the LT Auditor ^MP server that will listen for incoming syslog connections from your OpenText systems.

Use a specific IP address if your LT Auditor ^MP server has multiple network interfaces and you want to restrict syslog reception to a specific one. Use 0.0.0.0 to accept connections on any interface.

Port Number: The port the transformation rule listens on for incoming syslog data.

If you change the default port, ensure the new port is:

• Not already in use by another service on the LT Auditor ^MP server
• Open in your firewall between the OpenText servers and the LT Auditor ^MP server
• Updated in the syslog forwarding configuration on your eDirectory and OES servers to match

Communication Protocol: The transport protocol used for the syslog connection between your OpenText servers and LT Auditor ^MP.

TLS configuration (if TLS is selected):

If TLS is selected as the protocol, additional settings are required:

[Your administrator should coordinate with your PKI or security team to obtain the appropriate certificates before enabling TLS.]

3. Click Save to apply your changes

Changes to transformation rule settings take effect immediately. If eDirectory or NSS servers are already forwarding logs to LT Auditor ^MP, updating the port or protocol will interrupt collection until the syslog forwarding configuration on those servers is updated to match.

Confirming the firewall allows the configured ports:

After reviewing or updating the transformation rule settings, confirm that your firewall allows inbound traffic on the configured ports from your OpenText servers to the LT Auditor ^MP server.

Test connectivity from an OES server to the LT Auditor ^MP server:

nc -zv <LT_AuditorMP_Host> <Port>

A successful response confirms the port is open and reachable. If the connection fails, review your firewall rules to ensure the required port is permitted.

[Your administrator should document the configured ports and protocols for both the eDirectory and NSS transformation rules so that OpenText system administrators can configure syslog forwarding to match.]

Duplicating transformation rules:

If your environment has multiple eDirectory servers or OES NSS servers that require different port assignments or protocol configurations, you can duplicate an existing transformation rule and modify the copy:

1. In the Configure page, locate the transformation rule to duplicate
2. Click the three vertical action buttons
3. Select Duplicate
4. Edit the duplicated rule with the new port or protocol settings
5. Click Save

This allows you to maintain separate receiver configurations for different OpenText systems in your environment.

Viewing transformation rule history:

LT Auditor ^MP maintains a version history of transformation rule configurations:

1. Open the transformation rule
2. Click View History
3. Review previous versions with timestamps
4. Revert to a previous version if needed

This is useful if a recent configuration change has caused collection issues and you need to restore a previously working configuration.

Best practices:

• Review transformation rule settings before configuring syslog forwarding on your OpenText systems — the port and protocol must match on both ends
• Use TCP or TLS rather than UDP in production environments for reliable log delivery
• Document the configured ports and protocols for all transformation rules and share them with your OpenText system administrator
• Test firewall connectivity from each OpenText server to the LT Auditor ^MP server before configuring syslog forwarding to catch network issues early
• Change default ports only if necessary — using standard ports simplifies troubleshooting and documentation
• If enabling TLS, coordinate certificate management with your PKI team well in advance of go-live

[Your administrator should include the eDirectory and NSS transformation rule port and protocol settings in your network documentation so firewall administrators can maintain the correct rules over time.]

Every LDAP server in your environment must be configured to forward eDirectory audit logs. Missing even one server will result in gaps in your audit data that may affect compliance reporting and incident investigation.

Understanding CEF audit log forwarding:

eDirectory generates audit log data in CEF format and forwards it via syslog to a configured destination — in this case, the LT Auditor ^MP server. There are two ways to configure this forwarding depending on your environment:

Both methods produce the same result — CEF audit events forwarded to LT Auditor ^MP on port 5014 (or your configured port).

Before you begin:

Confirm the following on each eDirectory server before proceeding:

• The LT Auditor ^MP transformation rule for eDirectory is configured and the server is listening on port 5014 (or your configured port) — see the Modifying Receiver Settings in LT Auditor ^MP article
• The firewall allows outbound syslog traffic from the eDirectory server to the LT Auditor ^MP server on the configured port
• You have administrative access to each eDirectory server — either via iManager or direct server access for configuration file editing

Option A — Configure via iManager (GUI):

Use this method if you prefer a graphical interface or are configuring a small number of eDirectory servers.

1. Open a browser and log in to iManager for the eDirectory server you are configuring
2. Navigate to eDirectory Auditing
3. Select your LDAP NCP server from the server list
4. Select CEF as the audit output format
5. Configure the syslog destination:
   • Host — the IP address or hostname of the LT Auditor ^MP server
   • Port — 5014 (or your configured port)
   • Protocol — TCP, UDP, or TLS to match your LT Auditor ^MP transformation rule setting
6. Enable the following event categories and save:

7. Click Save
8. Verify the configuration is active and eDirectory begins forwarding logs

[Your administrator should add screenshots of each iManager screen here to guide administrators who are less familiar with the iManager interface.]

Option B — Configure via configuration file (SLES LDAP Server):

Use this method for SLES Linux LDAP servers, large deployments, or where iManager access is not available.

Step 1 — Edit the audit log configuration file:

Open the audit configuration file on the eDirectory server:

sudo nano /etc/opt/novell/eDirectory/conf/auditlogconfig.properties

Uncomment and update the following lines. The example below uses TCP — replace TCP with UDP or TLS if required by your environment:

log4j.rootLogger=debug, S

log4j.appender.S=org.apache.log4j.net.SyslogAppender

log4j.appender.S.Host=<IP Address of LT Auditor MP>

log4j.appender.S.Port=5014

log4j.appender.S.Protocol=TCP

log4j.appender.S.Threshold=INFO

log4j.appender.S.CacheEnabled=no

log4j.appender.S.layout=org.apache.log4j.PatternLayout

log4j.appender.S.layout.ConversionPattern=%c: %m%n

Replace <IP Address of LT Auditor MP> with the actual IP address or hostname of your LT Auditor ^MP server.

Protocol options:

Save the file after making your changes.

Step 2 — Update the modules configuration file:

To ensure the CEF audit daemon restarts automatically when eDirectory is restarted or the server reboots, add the following line to the modules configuration file:

Open the file:

sudo nano /etc/opt/novell/eDirectory/conf/ndsmodules.conf

Add the following line:

cefauditds   auto     #cefauditds

Save the file.

Step 3 — Restart the CEF audit daemon:

Apply the configuration changes by restarting the CEF audit daemon:

ndstrace –c “unload cefauditds”

ndstrace –c “load cefauditds”

The daemon will restart and begin forwarding eDirectory CEF audit events to the LT Auditor ^MP server on the configured port.

Verifying eDirectory log forwarding:

After configuring syslog forwarding on the eDirectory server, verify that LT Auditor ^MP is receiving the data:

1. Log in to the LT Auditor ^MP Web UI
2. Navigate to View
3. Select the eDirectory environment and category
4. Set the date range to Last 15–30 minutes
5. Confirm that eDirectory events are appearing in the event list

If no events appear:

Confirm the CEF audit daemon is running on the eDirectory server:
ndstrace –c “modules” | grep cefauditds

• Confirm no firewall is blocking outbound syslog traffic from the eDirectory server to the LT Auditor ^MP server on port 5014
• Confirm the IP address and port in the configuration file match the LT Auditor ^MP transformation rule settings
• Review the eDirectory server logs for any errors related to the CEF audit module

Repeating configuration across all eDirectory servers:

Repeat the configuration steps above — using either Option A or Option B — for every eDirectory LDAP server in your environment. Each server must be individually configured to forward its audit logs to LT Auditor ^MP.

To confirm all servers are forwarding:

1. Navigate to View in the LT Auditor ^MP Web UI
2. Filter by Source or Host and confirm events are appearing from each eDirectory server
3. If any server is not appearing as a source, revisit the configuration on that server

[Your administrator should maintain a list of all eDirectory servers in the environment and confirm each one has been configured and verified before considering the deployment complete.]

Caching behavior during LT Auditor ^MP outages:

The eDirectory CEF audit configuration supports log caching to prevent data loss during temporary connectivity interruptions:

• When CacheEnabled=no is set (as in the configuration above), events are not cached locally — if the LT Auditor ^MP server is temporarily unavailable, events generated during that period will be lost

To enable caching and ensure no audit events are lost during outages, change the setting:
log4j.appender.S.CacheEnabled=yes

• When caching is enabled, events are stored locally on the eDirectory server and automatically forwarded to LT Auditor ^MP once connectivity is restored

[Your administrator should determine whether caching is required based on your organization’s audit data retention and compliance requirements. For compliance-critical environments, enabling caching is recommended.]

Best practices:

• Configure all eDirectory servers before considering the deployment complete — a single unconfigured server represents a monitoring gap
• Use TCP or TLS in production environments for reliable log delivery
• Enable caching if your compliance requirements mandate that no audit events are lost during connectivity interruptions
• Test log forwarding from each server individually after configuration rather than assuming all servers are working correctly
• Document which eDirectory servers have been configured, the protocol and port used, and the date of configuration
• Coordinate with your network team to confirm firewall rules are in place for all eDirectory servers — not just the first one you configure
• Add screenshots of the iManager configuration screens to the Option A section of this article to assist administrators less familiar with iManager

[Your administrator should revisit this configuration whenever new eDirectory servers are added to the environment, or when the LT Auditor ^MP server IP address or syslog port changes.]

Understanding the NSS Audit Agent:

Unlike eDirectory auditing which is configured directly within eDirectory itself, NSS file activity auditing requires a separate agent component — the LT Auditor ^MP OES module — to be installed on each OES server hosting NSS volumes. The agent:

• Monitors file system activity on NSS volumes in real time
• Captures file reads, writes, deletions, renames, and permission changes
• Forwards collected activity to LT Auditor ^MP via syslog
• Caches audit streams locally if the LT Auditor ^MP server is temporarily unavailable and automatically resends once connectivity is restored — no audit data is lost during outages

The agent must be installed individually on each OES server you want to monitor. Missing even one server results in a gap in your NSS file activity audit data.

Prerequisites:

Before installing the NSS Audit Agent, confirm the following on each target OES server:

[Your administrator should confirm the current version of the agent package and where to obtain it for your environment.]

Step 1 — Copy the agent package to the OES server:

Copy the agent RPM package to the target OES server. The package filename follows the format:

LTAuditorMP-OES-25.0.0.0-0.x86_64.rpm

[Your administrator should note the current package filename and version used in your environment here.]

Step 2 — Switch to root:

Open a terminal on the OES server and switch to root:

su

Enter the root password when prompted.

Step 3 — Install the agent package:

Install the RPM package using the following command:

rpm -ivh LTAuditorMP-OES-25.0.0.0-0.x86_64.rpm

The agent installs to:

/opt/bluelance/

The installation process:

• Installs the agent binaries and configuration files to /opt/bluelance/
• Registers the ltaudit service with systemd
• Does not start the service automatically — configuration must be completed first

Step 4 — Configure syslog forwarding:

Navigate to the agent bin directory and run the configuration script:

cd /opt/bluelance/bin

./update_syslog_config.sh

The script will prompt you for the following information:

Host/IP of the LT Auditor ^MP server: Enter the IP address or hostname of your LT Auditor ^MP server:

Enter LT Auditor ^MP host: <LT_AuditorMP_IP_or_Hostname>

Port: Enter the port configured in the LT Auditor ^MP NSS transformation rule (default: 5015):

Enter port [default: 5015]: 5015

Protocol: Select the communication protocol to match your LT Auditor ^MP NSS transformation rule:

Enter protocol [UDP/TCP/TLS, default: TCP]: TCP

If TLS is selected, you will be prompted for additional settings:

[Your administrator should update the TLS defaults above with the actual values used in your environment if TLS is selected.]

Once all prompts are completed, the configuration script automatically saves the settings and starts the required daemons.

Step 5 — Configure the firewall:

Ensure no firewall is blocking outbound traffic from the OES server to the LT Auditor ^MP server on the configured syslog port.

Test connectivity from the OES server:

nc -zv <LT_AuditorMP_Host> <Port>

A successful response confirms the connection is open. If the connection fails, review your firewall rules to permit outbound traffic on the configured port.

Step 6 — Verify the agent service is running:

After the configuration script completes, confirm the ltaudit service is running:

Using systemctl:

systemctl status ltaudit.service

Using the control script:

/opt/bluelance/bin/ltaudit.rc status

The service should show as active (running). If the service is not running, check the agent logs for errors before proceeding.

Step 7 — Verify audit log collection:

After confirming the service is running, verify that NSS audit data is being collected and forwarded to LT Auditor ^MP:

Check NSS audit status:

cat /opt/bluelance/log/nssstatus.log

Confirm the file contains:

Successfully opened live vigil file

This message confirms the agent has successfully connected to the NSS audit subsystem and is collecting file activity data.

Review general application logs:

ls /opt/bluelance/logs/

Check for forwarding failures:

cat /opt/bluelance/log/syslog_send.log

Review this log for any errors related to forwarding data to the LT Auditor ^MP server.

Step 8 — Verify data in LT Auditor ^MP:

Confirm that NSS file activity data is appearing in LT Auditor ^MP:

1. Log in to the LT Auditor ^MP Web UI
2. Navigate to View
3. Select the NSS environment and category
4. Set the date range to Last 15–30 minutes
5. Perform a file operation on an NSS volume on the configured server (e.g., create or modify a file)
6. Confirm the event appears in the LT Auditor ^MP event list within a short period

If no events appear:

• Confirm the ltaudit service is running on the OES server
• Confirm the nssstatus.log shows Successfully opened live vigil file
• Confirm no firewall is blocking traffic on the configured syslog port
• Confirm the port and protocol in the agent configuration match the LT Auditor ^MP NSS transformation rule settings
• Review the syslog_send.log for forwarding errors

Managing the NSS Audit Agent service:

Use the following commands to manage the ltaudit service after installation:

Using systemctl:

# Start the service

systemctl start ltaudit.service

# Stop the service

systemctl stop ltaudit.service

# Restart the service

systemctl restart ltaudit.service

# Check service status

systemctl status ltaudit.service

# Enable the service to start automatically on boot

systemctl enable ltaudit.service

Using the control script:

# Start the service

/opt/bluelance/bin/ltaudit.rc start

# Stop the service

/opt/bluelance/bin/ltaudit.rc stop

# Check service status

/opt/bluelance/bin/ltaudit.rc status

Enable the service to start automatically on boot using systemctl enable ltaudit.service to ensure NSS audit collection resumes automatically after a server reboot without manual intervention.

Caching behavior during LT Auditor ^MP outages:

If the LT Auditor ^MP server is temporarily unavailable, the NSS Audit Agent automatically caches audit streams locally on the OES server. Once connectivity to the LT Auditor ^MP server is restored, the cached data is automatically forwarded — no NSS audit events are lost during outages.

This behavior is built into the agent and requires no additional configuration.

Repeating installation across all OES servers:

Repeat all steps in this article for every OES server in your environment that hosts NSS volumes you want to monitor. Each server must have the agent installed and configured individually.

To confirm all servers are forwarding:

1. Navigate to View in the LT Auditor ^MP Web UI
2. Filter by Source or Host
3. Confirm NSS file activity events are appearing from each OES server
4. If any server is not appearing as a source, revisit the installation and configuration on that server

[Your administrator should maintain a list of all OES servers in the environment, confirm each one has been installed and verified, and document the agent version, configuration date, and protocol used for each server.]

Uninstalling the NSS Audit Agent:

If the agent needs to be removed from an OES server:

1. Stop the service:

systemctl stop ltaudit.service

2. Remove the RPM package:

rpm -e LTAuditorMP-OES

3. Confirm the package has been removed:

rpm -qa | grep LTAuditorMP

No output confirms the package has been successfully removed.

Best practices:

• Install the agent on all OES servers hosting NSS volumes before considering the deployment complete — a single unmonitored server is a gap in your audit coverage
• Always verify the nssstatus.log after installation to confirm the agent has successfully connected to the NSS audit subsystem
• Enable the ltaudit service to start automatically on boot on every OES server to prevent monitoring gaps after reboots
• Use TCP or TLS in production environments for reliable log delivery
• Test firewall connectivity before running the configuration script to catch network issues early
• Document the agent version, configuration date, port, and protocol for each OES server
• Include NSS Audit Agent installation in your OES server provisioning checklist so new servers are automatically configured for monitoring when they are deployed

[Your administrator should revisit agent installations whenever the LT Auditor ^MP server IP address or NSS syslog port changes, as the agent configuration will need to be updated on every OES server to reflect the new values.]

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

Before installing and configuring Azure Log Connector, several prerequisites must be in place in both your Microsoft Azure environment and your LT Auditor ^MP deployment. This article covers everything that needs to be confirmed or prepared before proceeding with installation.

LT Auditor ^MP prerequisites:

[Your administrator should confirm the exact download location for the Azure Log Connector package in your environment.]

Server requirements:

The machine where Azure Log Connector will be installed must meet the following requirements:

Required outbound network access:

Azure Log Connector requires outbound HTTPS access to the following Microsoft API endpoints. Confirm these are not blocked by your firewall or proxy:

Test connectivity from the Azure Log Connector server to each endpoint:

Test-NetConnection -ComputerName graph.microsoft.com -Port 443

Test-NetConnection -ComputerName manage.office.com -Port 443

Test-NetConnection -ComputerName login.microsoftonline.com -Port 443

All three should return a successful result. If any connection fails, work with your network team to allow outbound HTTPS traffic to those endpoints.

[Your administrator should confirm whether outbound internet access from the installation server requires proxy configuration, and if so, ensure the proxy settings are configured before proceeding.]

Microsoft Entra ID prerequisites:

Required API permissions:

The App Registration used by Azure Log Connector requires the following permissions. All permissions are Application type — not Delegated — as Azure Log Connector runs as a background service without a signed-in user. All permissions require Admin Consent from a Global Administrator.

Microsoft Graph — Application Permissions:

Office 365 Management APIs — Application Permissions:

This is a significantly broader set of permissions than the previous EntraConnector module required, reflecting the expanded scope of Azure Log Connector across both Entra ID and Microsoft 365. All permissions require Admin Consent before they become active.

Microsoft 365 license requirements:

Access to certain log categories requires appropriate Microsoft licensing. Confirm the following with your Microsoft licensing administrator:

[Your administrator should confirm your organization’s current Microsoft 365 and Entra ID license tiers and which log categories are available before configuring Azure Log Connector.]

Roles required for setup:

[Your administrator should coordinate with your Azure or Microsoft 365 administrator to complete the App Registration steps if they do not have access to the Azure Portal.]

Information to gather before installation:

Before proceeding to the App Registration and installation steps, gather the following. You will need all of these values during configuration:

The Client Secret value is only displayed once at the time of creation. Copy it immediately and store it securely. If the secret is lost, a new one must be generated.

Prerequisites checklist:

Before proceeding to the next article, confirm all of the following:

• [ ] Installation server meets Windows Server 2019 or newer requirement
• [ ] Outbound HTTPS access confirmed to all three Microsoft API endpoints
• [ ] LT Auditor ^MP server is installed and running
• [ ] LT Auditor ^MP syslog listener is active on the configured port
• [ ] Azure Portal access with appropriate privileges is available
• [ ] Microsoft 365 and Entra ID license tiers confirmed
• [ ] Tenant ID, Client ID, and Client Secret are ready to hand
• [ ] LT Auditor ^MP syslog port and protocol are confirmed

[Your administrator should complete this checklist before proceeding to the Registering the App in Microsoft Entra ID article to avoid interruptions during setup.]

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 client agent is Online in the PII Scanner Server web UI
• The agent has read access to the path you want to scan
• At least one target host (LT Auditor ^MP) is configured in Admin → Target Hosts
• The PII detection rules relevant to your scan are enabled in Admin → PII Patterns
• No firewall is blocking communication between the agent and the PII Scanner Server or between the PII Scanner Server and LT Auditor ^MP

Running an on-demand scan:

Log in to the PII Scanner Server web UI at:

https://<PII_Scanner_Server_IP>:52766

2. Navigate to Admin → 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:
   
   • On-Demand — HR Share Audit Prep — May 2026
   • Incident Response Scan — FileServer01 — 2026-05-15
   • 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

5.  Leave blank to scan all file types for a comprehensive sweep.
   
   PII Classes Select the PII detection patterns relevant to this scan. For an incident response or audit scan, consider enabling all available classes for maximum coverage.
   
   Target Host Select your LT Auditor ^MP server as the destination for scan results.
   
6. Click Queue Job
   

The job is submitted immediately with a status of Queued. The assigned agent will claim it on its next poll cycle (default: every 1 minute) and begin scanning.

Monitoring the scan in progress:

1. Navigate to Admin → Jobs
2. Locate your job — the status will update from Queued to Running once the agent claims it
3. Review the job progress:
   • Started — the time the agent began scanning
   • Records Processed — the number of files scanned so far
   • Status — current state of the job
4. Refresh the page periodically to see updated progress

For large directories, scans can take a significant amount of time. The agent scans files sequentially and forwards matches to LT Auditor ^MP in real time as they are found — you do not need to wait for the scan to complete to begin 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 environment and category configured to receive PII Scanner data
4. Set the date range to Today or Last Hour
5. Filter by Source — PII Scanner
6. Results will populate as the agent finds and forwards matches
7. Click any result row to view full details:
   • File Path — where the PII was found
   • PII Class — the type of sensitive data matched
   • Line Number and Context — the location and surrounding content in the file
   • Timestamp — when the match was detected
   • Agent — which client agent performed the scan

Confirming scan completion:

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

If the job status shows Failed:

1. Review the error details in the job record
   

Check the agent logs for more specific error information:

Linux:

cat /opt/bluelance/scanner/scanner.log

 Windows:

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

3. Resolve the identified issue and requeue the job 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, 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 queuing an on-demand scan — a job assigned to an offline agent will remain in Queued status until the agent comes back online
• For incident response scans, enable all PII classes for maximum coverage rather than limiting to a subset
• Use specific, descriptive job names that capture the date, scope, and reason for the scan so the jobs list serves as an auditable record
• For very large directories, consider breaking the scan into multiple smaller jobs by subdirectory — this makes progress easier to monitor and reduces the impact of a failure partway through
• Begin reviewing results in LT Auditor ^MP as the scan runs rather than waiting for completion — this is especially important during incident response when time is critical
• Export and retain scan results immediately after completion, particularly for incident response or audit-driven scans

[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 (e.g., Social Security Number, Credit Card Number)
• Severity — the severity level assigned to the detected PII class (Critical, High, Medium, Low)
• Line Number — the line in the file where the match was found
• Context — a snippet of the surrounding content to help identify the match
• 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
• Target Host — the LT Auditor ^MP instance the result was forwarded to

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 scan job:

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 In
   • Value — the PII class to focus on (e.g., Social Security Number)
3. Click Apply Filters

Filter by severity:

1. Click Advanced Filters
2. Add a condition:
   • Field — Severity
   • Operator — Equals
   • Value — Critical, High, Medium, or Low
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 (e.g., \\fileserver01\shares\HR)
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 (e.g., an HR file server with appropriate permissions) is expected. PII found in unexpected locations (e.g., a public share, a developer’s home directory, or a temporary folder) requires immediate attention and remediation.

Is the PII class appropriate for the location? Credit card numbers in a Finance share may be expected. Credit card numbers in a Marketing share are not. Review whether the type of PII found makes sense for the location it was discovered in.

How severe is the finding? Prioritize Critical and High severity findings for immediate review. Medium and Low severity findings should be reviewed but may not require urgent action.

How many files are affected? A single match in one file is very different from thousands of matches across hundreds of 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
   • Severity — the assigned severity level
   • Line Number — where in the file the match was found
   • Context — surrounding content to help identify and validate the match
   • Timestamp — when the match was detected
   • Agent — which client agent found the match
   • Job Name — which scan job generated this result
   • Raw Log — the original forwarded syslog record
3. Click Close to return to the results table

Identifying false positives:

Not every match is a genuine PII finding. Some patterns may produce false positives — matches that technically satisfy the regex pattern but do not represent real sensitive data. For example:

• A 9-digit product code that matches an SSN pattern
• A test file containing sample data used for development
• A log file containing IP addresses matched by an IP address pattern

When reviewing results, use the Context field to validate whether a match represents real sensitive data. If a pattern is consistently generating false positives from a specific file type or location:

1. Review the detection rule in Admin → PII Patterns on the PII Scanner Server
2. Consider tightening the regex pattern to reduce false positives
3. Consider excluding the relevant file extension from future scan jobs if it consistently produces noise

Acting on scan results:

When genuine PII is found in an unexpected or unauthorized location, take the following steps:

1. Document the finding:

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

2. Assess the risk:

• Determine who has access to the location where the PII 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
• Confirm remediation by running a follow-up on-demand scan of the same path after the file has been 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
   • Severity
   • Timestamp
   • Agent
   • Job Name
5. Under Grouping, consider grouping by:
   • PII Class — to see a breakdown of finding types
   • Severity — to prioritize remediation efforts
   • 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 critical PII findings:

Configure LT Auditor ^MP to alert your team immediately when Critical or High severity PII is 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., Critical PII Finding Alert
   • Condition — Severity Equals Critical
   • Action — Alert
   • Recipients — your security or compliance team email addresses
5. Click Save and set to Active

Repeat for High severity findings if needed.

[Your administrator should also configure an alert for PII found in specific sensitive or unexpected locations, such as public shares or temporary directories.]

Best practices:

• Review scan results promptly after each scan completes — sensitive data findings should not sit unaddressed
• Prioritize Critical and High severity findings for immediate investigation and remediation
• Use the Context field to validate matches before acting on them — not every match is a genuine PII finding
• Export and retain scan results as part of your compliance evidence library, particularly for GDPR, HIPAA, and PCI-DSS audits
• Run a follow-up on-demand scan after remediation to confirm that 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 for Critical severity findings so your team is notified immediately rather than discovering findings during a scheduled review

[Your administrator should establish a regular cadence for reviewing accumulated scan results in LT Auditor ^MP — not just immediately after scans, but as part of an ongoing data governance review process.]

Understanding scan targets:

A scan target in PII Scanner consists of:

• A file system path — the directory, network share, or drive to be scanned
• A client agent — the agent that will execute the scan against that path
• File type filters — optional limits on which file extensions are included in the scan
• PII classes — the sensitive data patterns to look for during the scan

Scan targets are not configured as standalone objects in the PII Scanner administrative interface — they are defined as part of each individual scan job. Planning your targets in advance makes job creation faster and more consistent.

Planning your scan targets:

Before creating scan jobs, work through the following planning steps with your administrator:

1. Identify which file systems contain sensitive data:

Common locations that typically require scanning:

2. Identify which agent has access to each path:

Each scan job is executed by a single client agent. The selected agent must have:

• Network access to the target path
• Read permissions on the target directory and all subdirectories
• Sufficient resources (CPU, memory, disk I/O) to perform the scan without impacting other workloads

3. Determine which file types to include:

Scanning all file types provides the most complete coverage but increases scan time and resource usage. Consider filtering by extension for initial scans:

4. Confirm the LT Auditor ^MP target host:

All scan results are forwarded to LT Auditor ^MP via syslog. Confirm the LT Auditor ^MP target host is configured in the PII Scanner Server before creating scan jobs. See the Managing Target Hosts section below.

Configuring target hosts in the PII Scanner Server:

Before running any scans, configure where scan results will be sent — your LT Auditor ^MP syslog receiver.

Log in to the PII Scanner Server web UI at:
https://<PII_Scanner_Server_IP>:52766

2. Navigate to Admin → Target Hosts
3. Click Add Target
4. Configure the target host details:
   • Name — a friendly identifier (e.g., Production LT Auditor ^MP)
   • Target Server — the hostname or IP address of your LT Auditor ^MP server
   • Port — the syslog port configured in LT Auditor ^MP (default: 514)
   • Protocol — select UDP, TCP, or TLS

Protocol options:

Additional TLS configuration (if TLS is selected):

Example production target configuration:

• Name: Production LT Auditor ^MP
• Host: ltauditor.yourcompany.com
• Port: 6514
• Protocol: TLS
• Server Name: ltauditor.yourcompany.com
• Verify Certificate: Yes

5. Click Save

Configuring PII detection patterns:

PII Scanner uses regex-based patterns to identify sensitive data. Before running scans, review the available PII classes and confirm the right ones are enabled for your environment.

1. In the PII Scanner Server web UI, navigate to Admin → PII Patterns
2. Review the available PII classes:

3. Enable or disable individual PII classes using the Enabled toggle
4. Click the Edit icon to modify an existing pattern if needed
5. To add a custom pattern for organization-specific sensitive data:
   • Click Add Pattern
   • Enter a descriptive name
   • Enter the regex pattern
   • Set the severity level
   • Click Save

[Your administrator should review the default PII patterns and add any custom patterns required for your organization’s specific data types before running the first scan.]

Managing client agents:

Before assigning agents to scan jobs, confirm all agents are online and healthy.

1. Navigate to Admin → Clients in the PII Scanner Server web UI
2. Review the client list:

3. 
   Review each agent’s details:
   
   • Name — the machine hostname
   • IP Address — the last known IP address
   • Last Seen — the timestamp of the last check-in
4. If an agent shows as offline, check:
   
   • The LTA-Scanner service is running on that machine
   • The agent’s config.json points to the correct server IP and port
   • No firewall is blocking port 52766 between the agent and the server
5. To remove a decommissioned agent, click the Delete button next to it
   
   
   A deleted agent will automatically re-register on its next poll cycle if it is still active.
   
   

Best practices:

• Start with targeted, focused scans of your highest-risk directories before expanding to broader file system coverage
• Assign scan jobs to the agent closest to the target path to minimize network traffic during scanning
• Use file extension filters for initial scans to reduce scan time and focus on the most likely file types to contain PII
• Avoid scheduling broad scans during peak business hours — large scans can generate significant disk I/O on the scanned machine
• Confirm read permissions for the agent service account on all target paths before creating scan jobs to avoid permission errors mid-scan
• Review and update PII detection patterns regularly to ensure they reflect current data types in use in your organization
• Document your planned scan target inventory so the team has a clear picture of what is and is not in scope

[Your administrator should maintain a record of all configured target hosts and PII patterns, and review them whenever compliance requirements or the monitored environment changes.]