An important aspect of station security is an audit trail to record user activity. Any NiagaraAX station can be configured for user audits through use of the AuditHistoryService. While enabled, this service creates a history of user-initiated changes to components in the station.
If this service is not already in your station’s Services container, open the history palette and drag or copy the AuditHistoryService into your station’s Services folder.
The following sections provide more details:
AuditHistoryService configuration is simplified by having only the following writable properties:
-
Enabled
Either true (default) or false (disabled). Typically, you always leave this enabled.
-
History Config
Contains some read-only status properties and a few writable properties, including the following:
-
Capacity
Either:
Record Countnnnrecords (default is 500) orUnlimited. Typically, a very large number is acceptable for Supervisor stations, for example 250000 (in general the “Unlimited” choice is not the wisest even for a Supervisor), while in JACE stations history capacities are more appropriately set closer to the default 500 records or less. If a JACE station, the resulting AuditHistory is typically exported to a Supervisor station for archives. -
Full Policy
Either Roll (default) or Stop. In almost all cases, you leave full policy at roll to ensure latest user actions are recorded. Note the full policy has no effect if the capacity is “unlimited”.
-
System Tags
(Use optional). Allows using the System Tag feature for importing or exporting Niagara histories. For more details, see About System Tags.
-
The AuditHistory records user-initiated changes to property values, invoked actions, as well as any slots that are added, deleted, reordered, and renamed. Each record appears as a row that includes the timestamp of the change and the operation, plus other details including the responsible station user.
Using standard history views, you can review and resort data columns in the AuditHistory as needed to analyze user activity. Figure 269 shows an AuditHistory displayed in the HistoryTable view. In this view (as shown), you can double-click any row for a popup dialog displaying record details.
Standard fields in an AuditHistory record include the following:
-
Timestamp
Timestamp of when the operation on the slot became effective.
-
Operation
Type of user operation, which may include one of the following:
-
Added — Added a slot (typically a point or extension)
-
Changed — Changed a property (slot) value
-
Invoked — Issued a command to an action slot
-
Removed — Removed a slot (typically a point or extension)
-
Reordered — Reordered one or more slots
-
-
Target
Path to the container of affected slot, relative to the station root.
-
Slot Name
Name of the affected slot.
-
Old Value
Value of slot before a change.
-
Value
Value of slot after the change.
-
User Name
User name that initiated the operation.
Station login activities are included in a station’s AuditHistory. The following login-related events by either a Workbench (fox) user or a browser user appear in the station’s AuditHistory as records, as one of the following operations:
-
Login —valid user name and password supplied
-
Logout — close connection if Workbench, or explicit “
/logout” submission if browserIf a browser user simply closes the browser window, a logout audit record is not collected. Thus, a corresponding logout may not appear for every browser login, unless an explicit “/logout” is always forced. -
Login Failure — valid user name, but invalid password supplied
In any case, audit records are not produced for any disabled users (including users that are “locked out”) and for any unknown users.
Figure 270 shows various login-related records in an AuditHistory displayed in the HistoryTable view. As shown, you can double-click any row for a popup dialog displaying record details.
Specific to a security (station login-related) event, fields in a record are used as follows:
-
Timestamp
Timestamp of when the login/logout action occurred.
-
Operation
The security action that occurred, as either “Login”, “Logout”, or “Login Failure”.
-
Target
Depending on if a Workbench (fox) or browser (WebService) user connection, the path as either:
-
Workbench - Path to fox session, usually as
/Drivers/NiagaraNetwork/FoxService/etc. -
Browser - Path to the web service were validated, typically as
/Services/WebService
-
-
Slot Name
The remote host that attempted login/logout, typically by IP address.
-
Old Value
Not used.
-
Value
Not used unless the Operation is “Login Failure”, in which case the value indicates the number of consecutive failed login attempts (1—5). After 5 consecutive failed login attempts, if lockout is enabled, the user is locked out for some period of time. Subsequent login attempts during that period are not audited. Also see Lockout notes.
-
User Name
User name supplied during the attempted login/logout.