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