Logs and audit

DartRelay keeps two kinds of record. The audit log says who did what — sign-ins, sessions and administrators' changes — and lives in the console. The log files hold technical detail for diagnosing problems. This page explains both, and how to control how long and how much each keeps.

Audit log or log files?

The audit log

Go to System → Audit Log. Events are listed newest first, colour-coded by type, with the time, the account, the network address and the details.

What is recorded

• Sign-ins to the portal, the console and the client application, successful and failed. For a failed console sign-in, the entry gives the reason — the sign-in page itself deliberately says only "invalid username or password".
• Sessions starting and ending, and sessions ended by an administrator.
• Administrator actions — changes to settings, users, roles, resources and the other parts of the console, including changes to the log levels on the Logs page.
• Password changes, including forced changes, and self-service reset requests and results for real accounts.
• Blocked addresses being added, removed or having their note changed.
• Guest visitors signing in as the guest account, including whether they passed the human check.

Two things are deliberately not recorded, because they never reached an account and anyone could generate them in bulk: answers refused by the picture challenge, and password reset requests for names that match no account. Both are written to the log file instead.

Exporting

The audit log can be exported as a CSV file, for a spreadsheet or for your auditors. Exporting needs at least View permission on the audit log in the administrator's role. See Administrator roles and permissions.

Blocking an address from the audit log New in 2.0

Administrators with Full permission on Security see a Block button in the address column. It blocks that address from the portal and the console, after asking for a note; on an address already blocked everywhere it shows Unblock. Where an address cannot be blocked — the server itself, a trusted proxy, your own address and similar — the button is greyed out and hovering over it says why. See Blocked addresses.

How long the audit log is kept

1. Open the Logs page. Go to System → Logs.
2. Set the audit retention in days. 0 keeps everything, which is the default. Any other value must be at least 90 days.
3. Save.

Once a day DartRelay deletes audit entries older than the retention period, a batch at a time so that the database is not tied up. Entries are removed by age, never by count, so a night of failed sign-ins can never push out older administrator actions.

The log files

DartRelay writes two log files in its data directory (the App_Data folder inside the installation directory). The Logs page shows the full path of each file, so you never have to guess.

Older files carry a number on the end, such as .1, with .1 being the most recent.

Setting how much the portal log records

1. Open the Logs page. Go to System → Logs. The first card is the portal log.
2. Choose a Level. The more detailed levels, such as Debug, record more and fill the file faster; Error records only failures; Off records nothing.
3. Save. The new level takes effect immediately, without interrupting anyone.

Setting how much the session relay log records

The second card on the Logs page sets the level for the session relay log. Choose Not set to leave the decision to DartRelay's own default.

The session relay component reads its level only when it starts. So the card's save button also restarts that component, and only that component: the console stays up and nobody is signed out, but every open application and desktop session on this server is disconnected. The page asks you to confirm first. People can reconnect straight away, and their Windows sessions are still on the hosts.

• Because it disconnects sessions, this button needs the Endpoints permission as well as Settings.
• After a restart, the button cannot be used again for 90 seconds, so a double click cannot disconnect everyone twice.
• The page reports that the component "has been asked to restart"; check the log afterwards to confirm the new level.
• Both level changes and restarts are recorded in the audit log, because the log itself may be set to record very little.

Gathering logs for support

1. Raise the level of the relevant log to Debug, outside working hours if it is the session relay log.
2. Reproduce the problem, and note the time.
3. Collect the files from the path shown on the Logs page — the current file and the most recent numbered one.
4. Set the level back to its usual value.

Example

An auditor asks who changed the two-factor settings last quarter and who signed in to the console from outside the office. The administrator opens System → Audit Log, exports it as CSV, and filters the spreadsheet by event type and address. Afterwards they set the audit retention to 400 days on System → Logs, so a full year is always available.

If something goes wrong

The log file is empty or missing

Check the portal log's level is not Off. Check the path on the Logs page: if the usual file was in use by another copy of DartRelay — for example one started from a command prompt alongside the installed service — the second copy writes to a separate file with its process number in the name, and the page shows that path.

The audit log shows only one address for everyone

DartRelay is behind a proxy it does not trust. See the tip in The audit log.

A console sign-in fails with "invalid username or password" but the password is right

Read the matching audit entry: it records the real reason, such as the account not belonging to any administrator role.

The session relay log level did not change

The level applies only after the component restarts. If the restart could not complete, nothing was disconnected and the old level still applies. Check the portal log for the reason, wait for the 90 seconds to pass, and try again.

The retention setting is refused

Any value other than 0 must be at least 90 days.

Related pages