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

Prerequisites:

Before installing, confirm the following:

Download the PowerShell Orchestrator package:

[Your administrator should confirm whether packages are distributed internally or downloaded directly from the portal in your environment.]

Enabling WinRM on the installation machine:

If WinRM is not already enabled, run the following in PowerShell as Administrator:

Enable-PSRemoting -Force

Confirm WinRM is running:

Get-Service WinRM

The service should show as Running.

[Your administrator should confirm whether WinRM is managed via Group Policy in your environment before enabling it manually.]

Installation steps:

1. Copy the lta-mp-orchestrator.zip package to the target Windows machine
   
2. Extract the zip file to a working directory
   
3. Open PowerShell as Administrator and navigate to the extracted directory:
   

cd C:\path\to\extracted\orchestrator

4. If not already done, allow PowerShell scripts to run:

Set-ExecutionPolicy Unrestricted

5. Run the installation script:

.\Install.ps1

6. Follow any on-screen prompts during installation, including:
   
   • Entering the LT Auditor ^MP server IP address or hostname
   • Confirming the syslog port (default: 514)
   • Selecting the communication protocol (UDP, TCP, or TLS)
   • Entering the service account credentials to be used for Active Directory and Entra ID assessments
7. Once installation is complete, reset the PowerShell execution policy:
   

Set-ExecutionPolicy Restricted

[Your administrator should fill in the exact installer prompts and any environment-specific options that appear during installation.]

Post-installation verification:

After installation completes, confirm that PowerShell Orchestrator is running and communicating with the LT Auditor ^MP server.

1. Check the service status:

sc query PowerShellOrchestrator

The service should show as Running.

2. In the LT Auditor ^MP Web UI, navigate to Admin → Modules and confirm the PowerShell Orchestrator instance appears with a status of Connected
   
3. Check the PowerShell Orchestrator logs for any errors:
   

\Program Files\Blue Lance 2-0\PowerShellOrchestrator\Logs\

4. Verify that assessment data is appearing in the LT Auditor ^MP View module by navigating to View and selecting the Active Directory environment

If the module does not appear as connected in the Web UI, confirm that no firewall is blocking communication between the installation machine and the LT Auditor ^MP server on the configured syslog port.

[Your administrator should note the specific port, protocol, and service account used in your environment, and document which machine PowerShell Orchestrator is installed on.]

Verifying service account permissions:

The service account used by PowerShell Orchestrator requires the following minimum permissions:

Active Directory:

• Read access to all user, group, and computer objects in the monitored domains
• Read access to Group Policy Objects (GPOs)
• Read access to Active Directory Sites and Services

Microsoft Entra ID:

• Directory.Read.All — read access to directory objects
• AuditLog.Read.All — read access to audit logs
• Policy.Read.All — read access to conditional access and other policies

[Your administrator should confirm the exact permissions required in your environment and ensure the service account is configured accordingly before running the first assessment.]

Check service status:

sc query LTA_Web

sc query LTA_Server

sc query LTA_DataCollector

All three services should show as running. If any service is not running, check the logs for errors before continuing.

Check logs for errors or warnings:

\Program Files\Blue Lance 2-0\Web\Apps\Logs\

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

[Your administrator should note any expected output or common first-run messages specific to your environment.]

Check service status:

systemctl status lta-web

systemctl status lta-collector

Both services should show as active and running. If either service is not running, check the logs for errors before continuing.

Check logs for errors or warnings:

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

cd /opt/bluelance/web/server/logs/

[Your administrator should note any expected output or common first-run messages specific to your environment.]