Skip to main content
Skip table of contents

Managing Audit Logging

Audit logging is a feature in which every access to LightWave Server can be logged to a file or EMS collector in order to support security auditing. Audit logging is optional – it can be completely disabled, or selectively enabled for specific events or for specific objects. Additionally, logging can be restricted to 'failure' event outcomes only.

Audit Log Record Contents

Each audited event generates a single log record. Each log record contains the following standard information:

  • a timestamp 
  • the NonStop system name
  • the NonStop process name for LightWave Server
  • the object involved
  • the action attempted
  • the outcome (success, failure)
  • the remote IP address
  • the remote username
  • object- and/or event-specific details

Audit Objects

object namedescription
defaultwildcard; see below
acpAccess Control Policy
apidocAPI Swagger/OpenAPI
auditAudit settings
csrCertificate Signing Request
diaglogDiagnostic log
diaglog:settingsDiagnostic log settings
dialogPathway dialog
httplogHTTP log
httplog:settingsHTTP log settings
identityIdentity management
intermediateIntermediate certificate
processSERVER or SWORKER process
profileUser profile
serviceUser-defined service
sessionConsole user session
transactionTMF transaction
typeType subsystem

Audit Actions

actiondescriptionexample objects
defaultwildcard; see belowall
accessnon-specific access attemptall
controlbegin, commit or abortdialog, transaction
createcreate an objectacp, api, csr, dictionary, group, user, service, ...
deletedelete an objectacp, api, diaglog, dictionary, group, user, service, ...
executeexecuteapi, service
exportexport an objectapi, dictionary, service
importimport an objectapi, certificate, dictionary
installinstall an objectcertificate
listget list of objects of some typeacp, api, dictionary, group, user, service, ...
readread the details of an objectacp, api, apidoc, dictionary, group, user, service, ...
redeployredeploy an objectservice
renewrenew an objectcertificate
startstart an objectaudit, process, session
stopstop an objectaudit, process, session
takeovertakeover from backupprocess
updateupdate an objectacp, api, dictionary, group, user, service, ...

Audit Logging Configuration

Audit logging is configured in an EDIT file named AUDITCFG located in the same subvolume as the SERVER and SWORKER executable files. A default AUDITCFG file is supplied, with the setting enabled=0, meaning audit logging is disabled.

Since audit logging is intended to produce an audit trail for security purposes, the AUDITCFG file should be secured such that only authorized employees may edit the file.

The general format of AUDITCFG is:

enabled={ 0 | 1 }
appenders= <appender-name> [, <appender-name-2>] …



enabled is the global setting for audit logging. If not set to "1", audit logging will be disabled. 

appenders is a comma-separated list of 'log appenders'. Each log appender specifies a destination for logging events, (such as a file, or the NonStop Event Management System (EMS)) and one or more 'audit rules' that specify which audit events should be written to the destination and under what conditions they should be written. There can be multiple simultaneous appenders with destinations and audit rules. See ... for a description of <log-appender-settings>. 

monitor is the interval at which the AUDITCFG file should be checked for updates and automatically take effect. The value is specified in seconds. A value of 0 disables monitoring. Small values for monitor may impact peformance – a value of 15 or greater is recommended. 

Audit Rules

The general form of <audit-rules> is:

audit-<object>-<action> = { on | off | fail }
audit-<object>-<action>-severity = <severity-level> [, <failure-severity-level> ]


Where <object> is an auditable object type, e.g. user, session, process, etc. and <action> is an action that may be attempted on that object, .e.g. start, create, read, update, delete, etc. Any combination of object and action may be specified, however, there are many combinations for which events are not generated, e.g. audit-process-read.

With { on | fail | off } , ‘on’ specifies that both ‘success’ and ‘failure’ events should be logged, ‘fail’ specifies that only ‘failure’ events should be logged, ‘off’ specifies to no events should be logged

<severity-level> is a value 1, 2, or 3 that is logged along with the event. When <failure-severity-level> is also specified, <severity-level> is used with ‘success’ events and <failure-severity-level> is used with ‘failure’ events. It is up to the user to assign/interpret 1 as the highest or lowest severity. If not specified, a value of 2 will be used.

Events and Rule Matching

LightWave processes generate events in the form <object>-<action>-<outcome>, where outcome is 'success' or 'failure', for example: session-start-failure or user-update-success. When an event occurs, LightWave looks for an audit rule that matches the event's <object> and <action>. Then, the <outcome> of the event is evaluated against the matching audit rule's setting (on, off, fail) to determine if the event should actually be logged to the log destination (e.g. file). In the absence of a matching rule, the 'off' setting applies.

Default Action, Default Object

There is a special <action>, ‘default’, that is treated as a wildcard, and is used when no more specific rule has been specific.  Likewise there is a special <object>, ‘default’, that is treated as a wildcard and is used when no more specific rule has been specified. (The <action> default takes precedence over the <object> default.). Combining the two defaults, i.e. audit-default-default, creates a wildcard rule used when no specific, default action or default object setting has been specified.

For example, given the following entries:


If a 'session-start-success' (i.e. logon) event occurs, because there is no specific rule audit-session-start, the setting for audit-session-default, ‘on’, applies and the event would be logged.

If a 'process-start-success' event occurs, because there is no specific rule audit-process-start, and there is no audit-process-default rule, the setting for the audit-default-start rule, ‘fail’, applies and the event is not logged, though it would have if it had been a process-start-failure event.

If an 'api-execute-failure' event occurs, because there is no specific rule audit-api-execute, nor a rule audit-default-execute, nor a rule audit-api-default, the audit-default-default rule setting, 'off' applies, and the event is not logged regardless of the event outcome. Had the audit-default-default rule also been absent, the effect would be the same – if there is no matching rule, 'off' is assumed.

With regard to the audit-api-execute rule, “success” means that LightWave successfully processed the request and returned a reply, not that the api itself succeeded.

Audit Log Format

CEF Format

The audit log output format CEF is the “Common Event Format”. See ( for details.


CEF:0|NuWave|LightWave|1.6|process-start|process-start-success|2|phs=\\ATC.$S0400 start=2018-03-06T16:29:17Z cat=LWS-PROCESS object=\\ATC.$DATA13.LWS.SERVER caid=(29,2) paid=(29,2) filesystem=$DATA.LWS

CEF:0|NuWave|LightWave|1.6|user-update|user-update-failure|2|phs=\\ATC.$S0400 start=2018-03-06T21:41:22Z cat=LWS-PROCESS src= suser=admin method=POST request=/lightwave/api/v1/console/identity/user/4 message=malformed request

CEF:0|NuWave|LightWave|1.6|user-update|user-update-success|2|phs=\\ATC.$S0400 start=2018-03-06T21:41:49Z cat=LWS-PROCESS src= suser=admin user-id=4 password-change=false journal=name:John->Jean-Luc

CEF:0|NuWave|LightWave|1.6|session-start|session-start-failure|3|phs=\\ATC.$S0400 start=2018-03-06T21:58:36Z cat=LWS-PROCESS src= suser=anonymous method=POST request=/lightwave/api/v1/console/session message=invalid credentials

Update Events

When an update event occurs (for example, user-update-success), the CEF extension will contain a key, "journal", whose value will be a list of updated object properties in the form property-nameold-value -> new-value, property-nameold-value -> new-value, ...

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.