Master Audit Log
The master Audit Log
is available to site administrators from the Admin Console
- Select (Admin) > Site > Admin Console.
- Click the Settings tab.
- Under Management, click Audit Log.
- Use the dropdown to select the kind of activity to view. See below for detailed descriptions of each dropdown value.
The dropdown groups events as follows:
- Assay/Experiment events: Assay run import and deletion, assay publishing and recall.
- Attachment events: Adding, deleting, and downloading attachments on wiki pages and issues.
- Authentication Provider Configuration events: Enabling and disabling authentication providers, such as LDAP.
- Client API Actions: Errors raised by client API calls.
- Copy-to-Study Assay events: Events related to copying assay data into a study.
- Dataset events: Inserting, updating, and deleting datasets records. QC state changes.
- Domain events: Changes to column properties. Creating and deleting domains.
- Domain property events: Records per-property changes to any domain (list, dataset, specimen table, assay result, etc.). If a user changed 3 properties in a given domain, the "Domain events" log would record one event for changes to any properties; the "Domain property events" log would show all three events. The comment field of a domain property event shows the values of the attributes of the property that were created or changed, such as PHI level, URL, dimension, etc.)
- File batch events: Processing batches of files.
- File events: Changes to a file repository.
- Group events: The following group-related events are logged:
- Administrator created a group.
- Administrator deleted a group.
- Administrator added a user or group to a group.
- Administrator removed a user or group from a group.
- Administrator assigned a role to a user or group.
- Administrator unassigned a role from a user or group.
- Administrator renamed a group.
- Administrator configured a container to inherit permissions from its parent.
- Administrator configured a container to no longer inherit permissions from its parent.
- List events: Creating and deleting lists. Inserting, updating, and deleting records in lists.
- Logged sql queries: SQL queries sent to the database, including the date, the container, the user, and any impersonation information. Applies to SQL queries sent to the native database only; does not apply to external data sources. To log SQL queries from external data sources, see SQL Query Logging.
- Message events: Message board activity, such as email messages sent.
- Pipeline protocol events: Changes to pipeline protocols
- Project and Folder events: Creation, deletion, renaming, and moving of projects and folders. Changes to file roots are also audited.
- Query export events: Query exports to different formats, such as Excel, TSV, and script formats.
- Query update events: Changes to SQL queries, such as inserting and updating records in the query.
- Sample Set events: Records inserted and updated in sample sets.
- Search: Text searches requested by users.
- Site Settings events: Changes to the site settings made on the "Customize Site" and "Look and Feel Settings" pages.
- Specimen Comments and QC: Comments and QC changes in specimen repositories.
- Study events: Study events, including sharing of R reports with other users.
- User events: All user events are subject to the 10 minute timer. For example, the server will skip adding user events to the log if the same user signs in from the same location within 10 minutes of their initial login. If the user waits 10 minutes to login again then the server will log it.
- User added to the system (via an administrator, self sign-up, LDAP, or SSO authentication).
- User verified and chose a password.
- User logged in successfully (including the authentication provider used, whether it is database, LDAP, etc).
- User logged out.
- User login failed (including the reason for the failure, such as the user does not exist, incorrect password, etc). The IP address from which the attempt was made is logged for failed login attempts.
- User changed password.
- User reset password.
- User login disabled because too many login attempts were made.
- Administrator impersonated a user.
- Administrator stopped impersonating a user.
- Administrator changed a user's email address.
- Administrator reset a user's password.
- Administrator disabled a user's account.
- Administrator re-enabled a user's account.
- Administrator deleted a user's account.
Allowing Non-Admins to See the Audit Log
By default, only administrators can view audit log events and queries. If an administrator would like to grant access to read audit log information to a non-admin user or group, they can do so assigning the role "See Audit Log Events". For details see Security Roles Reference
Other event-specific logs are available in the following locations:
|Logged Event||Location of Log|
|Assays Copied to a Study||See Copy-To-Study History.|
|Datasets||Go to the dataset's properties page, click Show Import History. See Edit Dataset Properties.|
|ETL Jobs||See ETL: All Jobs History.|
|Files Web Part||See File Repository Administration.|
|Lists||See Manage Lists.|
|Project Users||Go to (Admin) > Folder > Project Users, then click History.|
|Queries (for external data sources)||See SQL Query Logging.|
|Site Users||Go to (Admin) > Site > Site Users, then click History.|
|All Site Errors||Go to (Admin) > Site > Admin Console > Settings and click View All Site Errors under Diagnostics. Shows the current contents of the labkey-errors.log file from the <CATALINA_HOME>/logs directory, which contains critical error messages from the main labkey.log file.|
|All Site Errors Since Reset||Go to (Admin) > Site > Admin Console > Settings and click View All Site Errors Since Reset under Diagnostics. View the contents of labkey-errors.log that have been written since the last time its offset was reset through the Reset Site Errors link.|
|Primary Site Log File||Go to (Admin) > Site > Admin Console > Settings and click View Primary Site Log File under Diagnostics. View the current contents of the labkey.log file from the <CATALINA_HOME>/logs directory, which contains all log output from LabKey Server.|
Setting Audit Detail Level
You can set the level of auditing detail on a table-by-table basis, determining the level of auditing for insert, update, and delete operations. Option include:
- NONE - No audit record.
- SUMMARY - Audit log reflects that a change was made, but does not mention the nature of the change.
- DETAILED - Provides full details on what change was made, including values before and after the change.
When set to detailed, the audit log records the fields changed, and the values before and after. A Details
link appears in the audit log, linking to full information.
The audit level is set by modifying the metadata XML attached to the table. For details see Query Metadata: Examples
Write Audit Log to File System
Audit Log messages can be written to the filesystem in addition to being stored in the database. Such additional archiving may be required for compliance with standards and other requirements.
To configure filesystem logging, an administrator edits the log4j.xml file, which is deployed to the $LABKEY_HOME/build/deploy/labkeywebapp/WEB-INF/classes directory. Note that any other options permitted by log4j
can be enabled, including writing the audit log content to the console, using multiple files, etc.
The administrator first creates a log name corresponding to the name of the particular log to record on the filesystem. For example, the GroupAuditEvent log would be written to "labkey.audit.GroupAuditEvent." Within the default log4j.xml file, there is a default template available showing how to include the audit logs and columns to be written to each designated file.
These log messages are not part of any transaction, so even if the writing of the audit event to the database fails, the writing to the filesystem will already have been attempted.
The format of audit messages written to the designated file(s) or other output source is:
<eventType> - key: value | key: value | …
UserAuditEvent - user: firstname.lastname@example.org (1003) | auditEventCreatedBy: email@example.com (1003)
| container: / (48d37d74-fbbb-1034-871f-73f01f3f7272) | comment: firstname.lastname@example.org logged in
successfully via Database authentication. |
Audit Event Types
The audit event types available for writing to the filesystem include, but are not limited to:
- AppPropsEvent - written upon change to a System setting (such as one of the Compliance settings)
- AssayPublishAuditEvent - written when an assay is published
- AttachmentAuditEvent - one action that triggers this is to attach a file to a message
- AuthenticationProviderConfiguration - written upon a change to authentication settings (e.g., enable/disable self-signon)
- ClientAPIActions - triggered when client script code explicitly calls the log
- ComplianceActivityAuditEvent - written from the complianceActivities module
- ContainerAuditEvent - creating or deleting containers are two examples
- DatasetAuditEvent -
- DomainAuditEvent - creating a new list will create a domain audit event
- GroupAuditEvent - creating or modifying a group will create one of these events
- ListAuditEvent - updating a list will create such an event
- LoggedQuery - written from the compliance module
- MessageAuditEvent - generated when an email message is sent