skip to content

A TACACS+ device-admin server answers an accounting REQUEST with TAC_PLUS_ACCT_STATUS_ERROR — what has happened to that record?

level: seniorimportance: should knowfreq 36%

answer

  1. only one status is a promise
  2. recorded, or not recorded
  3. no FAIL in this enumeration
  4. unreachable server, not a refusal
  5. the evidence is lost, not the action

basics

~20 s

It was not recorded. TACACS+ requires a server to answer SUCCESS only when it has actually stored the data and ERROR when it has not, so ERROR is a confirmed hole in the audit trail, not a verdict on the action.

solid answer

~50 s

`TAC_PLUS_ACCT_STATUS_ERROR := 0x02` means the server's processing did not complete and the data was not recorded. That answer is only useful because of the rule beside it: a server must reply `TAC_PLUS_ACCT_STATUS_SUCCESS := 0x01` **only** when the accounting request has actually been recorded, and must reply ERROR if it did not record it. Without that rule a SUCCESS would mean nothing more than a packet arrived. Note what ERROR is not: accounting has no FAIL status, because there is no negative verdict to give — the action was already decided elsewhere and the record merely describes it. The branch-wide meaning of ERROR applies here too: processing did not complete, so the client treats the server as it would an unreachable one rather than as one that said no. The action itself is untouched; what is missing is the evidence of it.

go deeper

for a junior

Remember the two outcomes that matter: SUCCESS means the server stored the record, ERROR means it did not. Neither says anything about whether the action described was allowed.

for a middle

Explain why the SUCCESS rule is what gives the log its weight, and why accounting has no FAIL status while authentication and authorization both do.

for a senior

Show the operational consequence: an ERROR is a known gap at a known moment, an unmatched task_id may be a delivery failure, and the device applied the change regardless of what was recorded.

for a principal

The tradeoff to own is how much an audit programme should rest on records a device produces about itself after the fact, and what a second, independent evidence path would cost against the gap it closes.

## Two statuses, and only one of them is a promise The accounting REPLY status enumeration is the smallest of the three on this protocol: `TAC_PLUS_ACCT_STATUS_SUCCESS := 0x01`, `TAC_PLUS_ACCT_STATUS_ERROR := 0x02` and `TAC_PLUS_ACCT_STATUS_FOLLOW := 0x21`. There is no PASS and no FAIL here, which is the first thing to say out loud: authentication and authorization each have their own enumeration and neither belongs in this sentence. What gives the accounting trail its evidential weight is a single normative rule about SUCCESS. The server must reply with success **only when the accounting request has actually been recorded**, and must reply ERROR when it did not record it. Strip that rule away and a SUCCESS would degrade into a transport acknowledgement — proof that a packet was parsed, not that a record exists. ## What ERROR means, and the three things it does not mean | It means | It does not mean | |---|---| | the server did not record this data | that the described action was refused | | processing did not complete on the server | that the device will undo anything | | the trail now has a gap at this point | that the operator did anything wrong | The second column is where candidates go wrong, because on the other two exchanges a negative answer is meaningful. Here it cannot be: by the time an accounting record is emitted, the decision has been taken and in the command-accounting case the command has been entered. There is nothing left for the server to veto, which is exactly why the enumeration has no FAIL. ## ERROR against FAIL, restated for this branch Across TACACS+ the distinction is the most consequential one on the protocol: - **ERROR** — the server's processing did not complete, the client cannot apply a result, and the client behaves as it would toward an unreachable server. - **FAIL** — processing completed and the answer is no. Accounting only ever produces the first kind. So the correct mental model for an accounting ERROR is *the server was, for this request, effectively not there*, and the client's reaction is a reachability reaction rather than a policy one. ## What this costs the person reading the log Consider a change made to a cold-chain monitoring switch at 02:40 and reviewed the next morning. The reviewer's questions are who, when and with what arguments, and every one of them is answered from records that exist. The consequences of ERROR are therefore asymmetric and worth stating precisely: - A **start record** that drew an ERROR leaves an event with no opening. The later stop record, if it arrives, references a `task_id` no start ever introduced. - A **stop record** that drew an ERROR leaves an open interval that looks identical to a task still running. - A **command accounting** record that drew an ERROR removes that command from the log entirely, and nothing in the remaining records hints that one is absent. - The device is unaffected in all three cases. The change was applied; only the evidence is missing. That last point is the honest limit of accounting as a control. It is an after-the-fact description produced by the device about itself, and a reviewer should treat absence of a record as *unknown*, not as *did not happen*. ## Operating with it The practical moves an engineer should be able to name are modest and all sit inside the protocol: 1. Treat the SUCCESS rate of accounting exchanges as a first-class signal — an ERROR is the device telling you the trail is incomplete at a known moment, which is far better than silence. 2. Expect a device that receives ERROR to fall back the way it would against an unreachable server, because that is what the status means. 3. Read an unmatched `task_id` as a possible delivery failure rather than a data anomaly, and check whether an ERROR was returned around that time. 4. Do not build a control that assumes a command cannot run unless its record was stored; the protocol makes no such guarantee, and the record is emitted after the fact. Finally, note the one status left over. `TAC_PLUS_ACCT_STATUS_FOLLOW := 0x21` is not a verdict on the record at all — it points the client at a different server to use. Reading it as a soft failure is a subtle error, because it says nothing about whether any data was stored.

  • If the accounting REPLY is ERROR, does the device undo the command the record described?
    No. The record is emitted after the action, and the protocol defines no rollback tied to an accounting outcome. The command has already been entered and applied; only the evidence of it is missing, which is a reviewer's problem rather than a device one.
  • Why does the accounting enumeration have no FAIL status?
    Because there is nothing to refuse. FAIL means processing completed and the answer is no, which presupposes a decision being asked for. An accounting REQUEST asks the server to record a fact, so the only outcomes are recorded, not recorded, or go to a different server.
  • What should a reviewer conclude from a period with no accounting records at all?
    That the period is unknown, not that it was quiet. Silence can mean no activity, records that were never delivered, or a client not configured to send them, and nothing inside the trail distinguishes the three. An ERROR is more informative than silence precisely because it is explicit.

saying these in an interview costs you the question

  • Reads an accounting ERROR as the command being denied
  • Thinks SUCCESS only acknowledges that the packet arrived
  • Expects a FAIL status in an accounting REPLY
  • Says an unrecorded command is automatically reversed by the device
  • Treats an empty log period as proof nothing happened
  • Reads FOLLOW as a soft failure to record