The question

Authentication decides who may enter and authorization decides what they may do; both are about the present. Accounting is the only one of the three that answers questions about the past, and the past is where every serious question lives. After an outage: which change, by whom, at what time, on which device, preceded it. After an intrusion: which account, from where, touched what. During an audit: show that the people who can change the infrastructure are known, that their changes are recorded, and that the record cannot be altered by the people it describes. Carriers built accounting to produce invoices, which is why the (Remote Authentication Dial-In User Service) attributes count octets; enterprises need it for the questions above, and most discover on the day of the question whether it was ever switched on.

's control catalogue, SP 800-53, states the requirement without reference to any protocol. Control AU-3, Content of Audit Records, requires that records establish "what type of event occurred", "when the event occurred", "where the event occurred", the "source of the event", the "outcome of the event", and the "identity of any individuals, subjects, or objects/entities associated with the event". AU-2 asks the organisation to "provide a rationale for why the event types selected for logging are deemed to be adequate to support after-the-fact investigations of incidents". AC-6(9) is six words long: "Log the execution of privileged functions." Those three controls are the specification; the rest of this article is how four record streams meet it for a network.

Stream one: RADIUS accounting, the network sessions

Every session admitted by RADIUS, an 802.1X login, a MAC Authentication Bypass session, a web-authenticated guest, a (virtual private network) user, can produce accounting records, and 2866, published in June 2000 by Rigney, defines them. The network access server sends Accounting-Request packets (code 4) to UDP port 1813 and the server acknowledges each with an Accounting-Response (5). The RFC recommends that "the client continue attempting to send the Accounting-Request packet until it receives an acknowledgement, using some form of backoff", so a short server outage delays records rather than losing them, and a long one produces a burst of delayed records when the server returns, which is worth knowing when reading timestamps.

The Acct-Status-Type attribute says what the record is: 1 Start, when the session begins; 2 Stop, when it ends; 3 Interim-Update, at the interval the device is configured for; 7 Accounting-On and 8 Accounting-Off, when the device itself starts or stops serving, which tells the server to close every session it still believes open on that device; further values for tunnels, and 15 for a failed attempt. The measurements are attributes: Acct-Session-Id, the identifier that ties a session's Start, updates and Stop together; Acct-Input-Octets, Acct-Output-Octets, Acct-Input-Packets and Acct-Output-Packets; Acct-Session-Time in seconds; Acct-Terminate-Cause for why it ended; Acct-Delay-Time for how long the record waited before being sent, which corrects the timestamp; Acct-Multi-Session-Id to link related sessions; Acct-Authentic to say who authenticated it. The User-Name, Calling-Station-Id and NAS identifiers from the authentication are repeated, and the Class attribute the server placed in the Access-Accept comes back unmodified, as RFC 2865 recommends, so a tag the policy engine attached at login is on every record of the session.

A Start and Stop pair therefore answers: this identity, on this device's , on this port of this switch or this access point, from this time to this time, moved this much traffic, and left for this reason. It does not say what the identity did while connected, which is what the next three streams are for.

Stream two: TACACS+ command accounting, the administrators

Administrators are the people whose actions matter most and whose sessions RADIUS accounting does not describe. accounting, in RFC 8907 of September 2020, is the third of the protocol's three packet types, 0x03, and because TACACS+ authorises commands one at a time, a device configured for command accounting sends a record for each command an administrator runs. The accounting REQUEST carries the same name=value arguments as authorization, so a command record names the service, the command and its arguments, and the time, plus a flag: START (0x02) at the beginning of a task, STOP (0x04) at its end, WATCHDOG (0x08) to report that a long task is still running. The server answers SUCCESS (0x01), ERROR (0x02) or FOLLOW (0x21). A session produces a START when the administrator logs in and a STOP when they leave; each command produces its own record in between.

That stream, kept on the server with the username, the device and the timestamp of each line, is the direct answer to who changed what. Its limits are the two every estate rediscovers: it exists only for devices where command accounting was configured and pointed at a reachable server, and only for the period the server retained. The companion article on TACACS+ walks the exchanges.

Stream three: syslog and the device's own change log

The device sees things no server is told about: interface state changes, authentication failures, process restarts, and, on platforms that support it, each configuration change as it is applied. Syslog is the . RFC 5424, published in March 2009 by Gerhards and obsoleting RFC 3164, defines a message of a header, optional structured data and an optional free-text message. The header carries a priority, "calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity", a version, a timestamp "derived from RFC 3339", the hostname, the application name, a process identifier and a message identifier. Severities run from 0 Emergency through 1 Alert, 2 Critical, 3 Error, 4 Warning, 5 Notice and 6 Informational to 7 Debug; facilities 4 and 10 are reserved for security and authorization messages and 16 to 23 for local use. The RFC specifies only the message and leaves transport to companion documents, UDP in RFC 5426 for compatibility and TLS in RFC 5425, and it says that "all implementations of this specification MUST support a TLS-based transport", which is the hint about how accounting data should cross a network. The syslog articles on this site cover the message field by field and the device-side configuration.

The device's own configuration change log is the stream most often unknown to the people who need it. Cisco's Configuration Change Notification and Logging feature, in the IOS XE configuration management guide, "allows the tracking of configuration changes entered on a per-session and per-user basis by implementing an archive function". It "saves configuration logs that track each configuration command that is applied, who applied the command, the parser return code (PRC) for the command, and the time the command was applied". It is disabled by default, keeps a configurable number of entries, between 1 and 1000 with a default of 100, can suppress password material from the log, and can send each entry to syslog as it happens, so that the change record reaches a collector even when the device is later replaced or wiped. A device with this enabled and forwarding to syslog has its own command accounting, independent of TACACS+, which is exactly the redundancy an investigation wants.

Stream four: configuration backups, what the commands did

Command records say what was typed; a configuration archive says what the device ended up with, and the difference between two archived configurations is the change itself, named or not. Configuration backup tools collect every device's running configuration on a schedule or on a change notification and store it in a version-controlled repository. Oxidized, which describes itself as "a network device configuration backup tool" and "a RANCID replacement", supports "over 130 operating system types", writes its output to git as the recommended store, and can trigger hooks, from running a command to posting a diff to a chat channel, when a configuration changes. A git history of configurations answers the question nobody enabled accounting for: the diff between Tuesday's commit and Wednesday's is the change, and the TACACS+ or syslog record from that window names the hand. NIST's CM-3, Configuration Change Control, asks organisations to "document configuration change decisions" and to "retain records of configuration-controlled changes to the system" for a defined period, and the archive is the cheapest way to have those records be true rather than aspirational.

Making the four streams one record

Four streams only answer the question if they can be joined, and the joins are designed, not assumed.

Clocks. Every record carries a timestamp from the device that produced it, in RFC 5424's RFC 3339 form or the RADIUS server's receipt time, and a correlation across devices is only as good as their agreement. Time synchronisation on every network device is an accounting control before it is anything else, and a device whose clock is wrong produces records that are confidently misleading.

Keys. RADIUS records join on Acct-Session-Id within a session, on User-Name and Calling-Station-Id across sessions, and on Class back to the policy that admitted them. TACACS+ records join on username, device and time. Syslog joins on hostname and time, and configuration-log entries carry the username as well. The device identity must be the same string in all four, which it is not by default: NAS-Identifier, the TACACS+ client address, the syslog hostname and the backup tool's inventory name are set in four places by four people.

Retention. Each stream has a default retention set by whoever installed it, and the question arrives later than any of them. The retention period is a decision to write down, per stream, against the longest look-back an investigation or a regulation can require.

Separation. The people who administer the network devices should not be the administrators of the servers that hold the records of what they did. NIST's AC-5 names the pattern in its discussion of separation of duties, "ensuring that security personnel who administer access control functions do not also administer audit functions", and the separation of duties entry on this site explains why a control one person can defeat alone is not a control. In a small team this is the hardest item on the list and the one an auditor checks first.

Transport. RADIUS accounting, TACACS+ and UDP syslog all cross the network in forms their own specifications describe as weak: RADIUS with and a shared secret, TACACS+ with what RFC 8907 calls obfuscation, syslog over UDP with nothing. RadSec for RADIUS, a protected management network for TACACS+ as RFC 8907 requires, and TLS syslog as RFC 5424 mandates support for, are the answers, and the records are worth more than the authentication traffic they describe.

The oldest finding

The failure that makes this article necessary is not a design flaw in any protocol. It is the device that was never configured to send accounting, the server that was never told to keep it, the configuration log left at its default of disabled, and the backup job that stopped running when the person who set it up left. Every one of the four streams is opt-in on the device, and every one has to be pointed at a destination that exists, is reachable, and is retained. The audit that finds the gap is the one conducted the morning after, and the control that prevents it is dull: an inventory of devices against the four streams, checked by a job rather than a person, with a record of the check itself.

What comes next in the series

The regulations that demand these records, from the Sarbanes-Oxley Act to , each have their own entries and will have their own explainers; this article is the common thread they pull on. The RADIUS and TACACS+ articles describe the two protocols' accounting sides in their own contexts, the syslog articles the message in detail, and the glossary entries for accounting, separation of duties, privilege creep and least privilege the vocabulary an auditor will use.

Sources