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

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