Aller au contenu

Logging & accounting

Every authentication, authorization and accounting (AAA) event that Taranac processes is recorded twice: as a structured, searchable record in the database (what you browse in the admin UI), and as a raw line in a forensic file log on disk. This page explains what each log type captures, how Taranac turns daemon output into records, where to view and export logs, how retention works, and how to walk through a real investigation.

The log views are read-only. You cannot edit or delete individual records from the UI — logs are immutable. They are removed only when their retention window expires.

How one daemon AAA event becomes a record: the file log is written first and is never suppressed, then exclusions, policy re-evaluation, and the enriched database insert follow.

Taranac keeps five separate log streams, three for TACACS+ and two for RADIUS. RADIUS has no separate authorization stream — under RADIUS, authorization happens inside the same Access-Request that authenticates the session.

StreamProtocolWhat it captures
AuthenticationTACACS+Login attempts: who tried to log in, from where, success or failure
AuthorizationTACACS+Command / service authorization: each command a device sent for a permit/deny decision
AccountingTACACS+Session and command accounting: starts, stops, watchdogs, elapsed time
AuthenticationRADIUSAccess-Request outcomes: Accept / Reject / Challenge, auth type, MFA result
AccountingRADIUSSession accounting: Start / Interim-Update / Stop, bytes transferred, framed IP

In the admin UI these surface as three pages: Authentication Log (TACACS+ and RADIUS on two tabs), Authorization Log (TACACS+ only), and Accounting Log (TACACS+ and RADIUS on two tabs).

Enrichment snapshot. Every log record stores a snapshot of related display values at the moment it was written: device name, device groups, the network object the NAS belongs to (and its type — host / subnet / range), the user’s display name, and the user’s groups. Because these are snapshots, a log row keeps the device and user names it had at write time even if you later rename or delete those objects. The underlying device_id / user_id links are set to null on deletion, but the log survives.

Node (cluster attribution). Every log record also stores the cluster node that processed it (node_id, resolved to a display node_name). On a single-node install this is simply your one node; under high availability it tells you which node handled a given authentication — useful when tracing a failover or an uneven load. All five AAA log streams carry it, and it surfaces as a Node column and a “filter by node” control. On single-node deployments the node filter is hidden (there is only one node to pick), so the column is informative but the filter only appears once a cluster has more than one node.

Matched rule. For TACACS+ authentication and authorization, each record shows which policy rule decided the outcome (rule_name, e.g. policy_1 or policy_default, plus the rule’s description as rule_label). Taranac determines this by re-evaluating the policy against the event, so the rule shown always reflects the policy as Taranac understands it. Accounting records do not carry a matched rule — accounting is not a policy decision.

Status. TACACS+ authentication is success / failure; authorization is permit / deny. RADIUS authentication is Accept / Reject / Challenge (Challenge means an MFA round-trip is in progress).

File log (forensic backup). In parallel with the database, every AAA event is also appended to a file on disk. The file log is a safety net: it is written first, before any exclusion or filtering is applied, so it captures events even for users you have deliberately excluded from database logging.

Understanding the pipeline helps when a log looks wrong or a field is empty.

The TACACS+ daemon (tac_plus-ng) streams every authentication, authorization and accounting event to Taranac’s parser. For each event the parser, in order:

  1. Writes the raw line to the file log (never suppressed).
  2. Checks the log-exclusion rules to decide whether to suppress this record in the database, in syslog forwarding, and/or in alerts — each channel independently.
  3. For authentication and authorization, re-evaluates the policy to fill in the matched rule and label.
  4. Inserts the enriched record into the database.
  5. Raises alerts where applicable (for example an auth failure, or an unknown device).
  6. Forwards to any configured syslog receivers.

A couple of field-mapping details worth knowing when reading TACACS+ logs:

  • The Line column is the NAS port/line (e.g. tty2) and Remote Address is the remote client IP. Either can be empty depending on the device.
  • TACACS+ accounting command data comes in two shapes. Command accounting stores the literal command (a trailing Cisco <cr> marker is stripped). Exec/session accounting stores key/value pairs (task_id, service, priv-lvl, elapsed time, start/stop time, disconnect cause, etc.), which Taranac parses into structured fields. Anything it does not recognise is preserved under “Unknown Fields”.

The RADIUS handler (inside FreeRADIUS) runs the full policy evaluation in-process for every Access-Request — WHO, WHERE, source, and time-of-day matching, first match wins. It logs the authentication outcome (with the matched rule order, profile name, MFA status, whether the password came from cache, and the auth duration in milliseconds), and queues accounting records as they arrive.

RADIUS records store the request attributes as structured data, with sensitive attributes (User-Password, CHAP-Password, MS-CHAP-*, EAP-Message) stripped before they are saved.

Open the Authentication, Authorization, or Accounting log page from the navigation. Each page shows a paginated, sortable table with a consistent layout.

Taranac TACACS+ and RADIUS authentication log with per-event detail The Authentication Log: protocol tabs (TACACS+ / RADIUS), filters, column toggles, and a row-click detail drawer.

Common UI behaviour across all log tables:

  • Timestamps are shown in your system-configured timezone, not raw UTC.
  • Username shows the login name in bold with the user’s display name beneath it; Device shows the device name (falling back to the NAS IP) with the IP in monospace below.
  • Node shows the cluster node that processed the record (blank on installs that predate node attribution). The column is always available to toggle on; the matching node filter appears only on a multi-node cluster.
  • Auto-refresh can be set to Off, 10s, 15s, 30s, or 1m from the toolbar. A green pulsing dot indicates it is active; refresh pauses automatically when the browser tab is hidden.
  • Column visibility is adjustable per table and remembered in your browser.
  • Row click opens a read-only detail drawer with every captured field, plus the raw daemon line (TACACS+) or raw RADIUS request/attributes at the bottom.

Each table offers a small set of column filters plus a free-text search. They behave differently, and choosing the right one matters:

ControlBehaviourUse it for
Username filterExact matchYou know the exact account name
NAS IP filterMatch by NAS IPNarrowing to one network device
Status filterSelect (e.g. success/failure, Accept/Reject)Isolating failures or rejects
Date rangeFrom / to (UTC)Bounding an investigation to a time window
Node filterSelect a cluster nodeNarrowing to one node on a high-availability cluster — only shown when more than one node exists
Search boxPartial match across username, NAS IP, device name, and user display nameYou only remember part of a name, or want device-name matches

The TACACS+ tables add filters relevant to that stream — Authorization can filter by Action and Service; Authentication can filter by matched rule and profile.

Default sort is newest first (timestamp descending). You can sort by timestamp, username, NAS IP, device name, user display name, status, and (for TACACS+) the matched rule, profile, or service.

Each log page has an Export action that produces an XLSX (default) or CSV file. Choose the scope:

  • Current view — exports exactly what you are looking at: the current page, with all active filters, search, and sort applied.
  • All entries — exports the full filtered set (ignoring pagination), capped at 10,000 rows.

Exports include all the enrichment snapshot columns, so an exported row is self-contained even months later.

Viewing and exporting logs both require the aaa_logs_view permission — see Roles & permissions.

Investigate a failed device login (TACACS+)

Section titled “Investigate a failed device login (TACACS+)”

A network engineer reports they cannot log in to a switch.

  1. Open Authentication Log → TACACS+ tab.
  2. Set the Status filter to failure and put the engineer’s account in the Username filter (or type a fragment into Search).
  3. Click the failing row. The detail drawer shows the NAS IP and device name, the line and remote address, the action message from the device, and crucially the matched rule — for example policy_default: Default catch-all, which tells you no specific rule matched and the request fell through to the default.
  4. If the device name is blank and only a NAS IP shows, the NAS is not registered in Network devices — that is usually the real problem.

Trace what a user actually did on a device (TACACS+)

Section titled “Trace what a user actually did on a device (TACACS+)”
  1. Open Authorization Log, filter by Username and NAS IP.
  2. The Command column shows each command the device sent for a permit/deny decision; the Action column shows whether it was permitted or denied.
  3. For session timing and disconnect reasons, switch to Accounting Log → TACACS+ and look at the elapsed time, start/stop times, and disconnect cause in the detail drawer.
  1. Open Authentication Log → RADIUS tab, set Status to Reject.
  2. The Reject Reason column tells you the stage and cause. Typical values:
Reject reasonMeaning
user_not_foundThe username is not known to Taranac
inactiveThe account exists but is disabled
lockedThe account is locked
bad_passwordPassword verification failed
no_policy_matchNo policy rule matched the request (implicit reject)
policy_denyA matching rule explicitly denies access
mfa_failedMFA was required and failed, or is not configured for the user
  1. Open the row to see the auth type, MFA status, whether the result came from the auth cache, and the raw (sanitised) RADIUS request.

Confirm a session and its data usage (RADIUS)

Section titled “Confirm a session and its data usage (RADIUS)”

Open Accounting Log → RADIUS. The Status column shows Start / Interim-Update / Stop; the detail drawer shows session duration, input/output bytes, framed IP, calling/called station, and terminate cause. A session with a Start but no Stop is still open (or the Stop was lost).

Question you’re askingGo to
Did this admin successfully log in to a device?Authentication Log → TACACS+
What commands did this admin run, and were they allowed?Authorization Log
How long was this device session, and how did it end?Accounting Log → TACACS+
Was this network user/host granted or denied access?Authentication Log → RADIUS
How much data did this session move, what IP/VLAN?Accounting Log → RADIUS
Was an MFA prompt issued or did MFA fail?Authentication Log → RADIUS (status Challenge / reject mfa_failed)
An event is missing from the UI logsCheck log exclusions, then the on-disk file log

The file log is independent of the database and of exclusion rules. It is the authoritative forensic record.

Files are organised by protocol, log type and month, one file per day:

{log_file_path}/{protocol}/{log_type}/{YYYYMM}/{YYYY-MM-DD}.log
/var/log/taranac/aaa/
├── tacacs/
│ ├── authentication/202606/2026-06-24.log
│ ├── authorization/202606/2026-06-24.log
│ └── accounting/202606/2026-06-24.log
└── radius/
├── authentication/202606/2026-06-24.log
└── accounting/202606/2026-06-24.log
  • TACACS+ files contain the raw lines from the daemon, one record per line, saved as-is.
  • RADIUS files are JSON-lines — one JSON object per line:
{"timestamp":"2026-06-24T12:34:56+00:00","username":"admin","nas_ip":"10.0.0.1","status":"accept","device_name":"sw-core-01"}

The base path defaults to /var/log/taranac/aaa, and file logging is on by default.

Database logs are pruned automatically by retention windows you control under Settings → System → Log Rotation. Editing a retention value goes through the standard settings API and requires the settings.edit permission.

SettingDefault (days)Applies to
tacacs.log_retention_days365The three TACACS+ logs
radius.log_retention_days365The two RADIUS logs

How pruning works: each of the five tables is range-partitioned by month in PostgreSQL. A daily maintenance job pre-creates upcoming monthly partitions, and a daily cleanup job drops whole monthly partitions once the entire month has aged past the retention window. Because expired data is removed by dropping a partition rather than deleting rows, cleanup is effectively instant and does not bloat the database. Partial (still-current) months are never dropped, and setting a retention value of 0 or less disables deletion entirely.

The same Log Rotation screen shows, per table, how it is partitioned, the oldest and newest months held, how far ahead partitions are pre-created, and which month the next cleanup will drop. It also offers buttons to run the partition and cleanup jobs on demand.

  • AAA policies — how the rules that decide permit/deny (and which log exclusions suppress records) are configured.
  • Network devices — registering NAS devices so logs show device names instead of bare IPs.
  • RBAC — the aaa_logs_view permission that gates these views and exports.
  • High availability — clustering, and the Node column that records which cluster node processed each row.
  • NAC authentication — endpoint (802.1X / MAB) authentication logging.
  • Get Taranac on GitHub