In TACACS+ device administration, which party sends an accounting REQUEST, and what is that exchange for?
answer
- the device speaks, not the human
- third of three separate exchanges
- written after the fact, not before
- one REQUEST, one REPLY, one pair
- SUCCESS or ERROR, never PASS
basics
~20 sThe network device sends it — in TACACS+ the client is the device, not the human at the keyboard. The accounting exchange is a REQUEST/REPLY pair asking the device-administration server to record what happened, after the fact.
solid answer
~40 sTACACS+ runs three independent exchanges and accounting is the third. The TACACS+ client is the network device itself, so the device — not the operator's terminal and not software on it — opens a TACACS+ session over TCP port 49, sends a packet of type `TAC_PLUS_ACCT := 0x03`, and the body carries a flags byte plus argument-value pairs such as `task_id`, `start_time` and, for command accounting, `service` and `cmd`. The device-administration server records the data and answers with a REPLY whose status is `TAC_PLUS_ACCT_STATUS_SUCCESS := 0x01`, `TAC_PLUS_ACCT_STATUS_ERROR := 0x02` or `TAC_PLUS_ACCT_STATUS_FOLLOW := 0x21`. Nothing is being decided in this exchange: the decision has already happened elsewhere, and this is the evidence of what followed.
go deeper
Recall the direction: the network device is the TACACS+ client and it sends the accounting REQUEST to the device-administration server, which records it and replies. Accounting is the third exchange and it describes, it does not decide.
Be able to name what is in the body — the flags byte, the identity fields and the argument-value pairs — and the three REPLY statuses, and to say why accounting has no PASS or FAIL.
Show that you know what the record is worth operationally: it is produced after the fact by the device, so it is an assertion by the device about itself, and its absence never reverses the action it would have described.
The tradeoff worth naming is where the audit obligation should live at all — in a protocol the devices already speak, or in a separate collection path with its own failure modes and its own cost.
## Three exchanges, and this is the one nobody watches live TACACS+ carries device-administration AAA as three **independent** exchanges over TCP port 49. Authentication establishes who the operator is. Authorization decides what they may do. **Accounting records what was done.** Each is its own TACACS+ session, named by a `session_id` in the 12-byte header, and the header's type field says which family a packet belongs to — accounting packets carry `TAC_PLUS_ACCT := 0x03`. The first two exchanges are consumed by the device in real time, because it cannot proceed without an answer. The third is consumed by somebody who was not in the room: an auditor, a reviewer after an outage, an engineer reconstructing a change at 02:40 on a cold-chain monitoring switch. That difference in reader is what makes accounting a distinct skill rather than a footnote to authorization. ## The client is the box, not the person The most common beginner error here is a vocabulary error. In TACACS+ the **client is any device that initiates TACACS+ requests** — the switch, the router, the console server. The engineer typing at a terminal is not a TACACS+ participant at all; they speak to the device's command-line interface, and the device speaks TACACS+ on their behalf. - The **client** (the network device) builds and sends the accounting REQUEST. - The **server** (the device-administration server) records the data and sends the REPLY. - The **operator** appears inside the record as data — a username, a terminal line, a remote address — never as a protocol endpoint. So a sentence such as *the client logs in and then sends its accounting record* is wrong twice over on this branch. ## What one accounting REQUEST carries The accounting REQUEST body holds, alongside the identity fields: - a **flags** byte saying whether a task is starting, still running, or finished — `TAC_PLUS_ACCT_FLAG_START := 0x02`, `TAC_PLUS_ACCT_FLAG_WATCHDOG := 0x08`, `TAC_PLUS_ACCT_FLAG_STOP := 0x04`; - the username the record is about, and the `port` field, which is free-format text naming the terminal line the login arrived on (the specification's own examples are strings such as tty10); - `rem_addr`, where the operator connected from; - `arg_cnt` argument-value pairs, each a name and a value joined by `'=' (0x3D)` for a mandatory argument or `'*' (0x2A)` for an optional one, capped at 255 characters per string. The argument-value pairs are where the substance lives: `task_id`, `start_time`, `stop_time`, `elapsed_time`, `timezone`, and for command accounting `service` and `cmd` with any `cmd-arg` pairs. Accounting arguments come first in the packet, ahead of any authorization arguments that also appear. ## What the REPLY can say Accounting has its own small status enumeration — and it is **not** the authentication or authorization one: | Status | Value | Meaning | |---|---|---| | `TAC_PLUS_ACCT_STATUS_SUCCESS` | `0x01` | the server has recorded the accounting data | | `TAC_PLUS_ACCT_STATUS_ERROR` | `0x02` | the server did not record it | | `TAC_PLUS_ACCT_STATUS_FOLLOW` | `0x21` | the server is pointing the client at a different server | There is **no PASS and no FAIL in accounting**. Those belong to the other two exchanges. A candidate who says *the accounting server returned FAIL, so the command was blocked* has merged three enumerations and two exchanges into one sentence. ## Why it is worth having as a separate exchange 1. It can run for actions the server never adjudicated, which is exactly what makes a command log complete rather than a summary of one decision path. 2. It can be emitted at the start of a task, at intervals while it runs, and at its end, so long-running work is visible before it finishes. 3. It produces a durable artifact whose reader is external to the transaction — the evidence of who changed a device, when, and with what arguments. The cost of that independence is honest to state: because the record is produced after the action has been decided, the absence of a record does not undo anything. The device did what it did whether or not the server wrote it down.
- If the operator is not a TACACS+ participant, how does their identity get into the accounting record?The device puts it there. It knows the username from the authentication exchange it ran earlier, and it copies that username, the terminal line in the `port` field and the remote address into the accounting REQUEST body it builds. The record's identity fields are the device's assertion, not the operator's.
- Does the accounting exchange reuse the session of the authorization exchange that preceded it?No. A TACACS+ session is one authentication sequence, one authorization exchange or one accounting exchange, each with its own `session_id`. They may travel over the same TCP connection when single-connection mode is in use, but they are separate sessions and a reader cannot join records by `session_id`.
- What kinds of task can accounting describe besides a typed command?A shell task with a start and a stop, a connection, and system events. The `event` argument exists for system accounting and takes values such as net_acct, cmd_acct, conn_acct, shell_acct, sys_acct and clock_change. Command accounting is the case device administration cares about most.
saying these in an interview costs you the question
- Says the operator's terminal software sends the accounting record
- Thinks the accounting exchange decides whether a command may run
- Expects an accounting REPLY status of PASS or FAIL
- Believes accounting rides inside the authorization REQUEST
- Calls the human being the TACACS+ client