skip to content

In TACACS+ accounting, what does task_id correlate, and what rules constrain the value a client puts there?

level: middleimportance: should knowfreq 42%

answer

  1. two records, one event
  2. join on the argument, not the header
  3. matching values on start and stop
  4. no reuse before the stop record
  5. opaque to the server, never parsed

basics

~20 s

The task_id argument ties a start record to its stop record: the two values must match. A client must not duplicate an active value or reuse one before sending its stop, and a server must assume nothing about its format.

solid answer

~50 s

`task_id` is the accounting argument that makes two records one event. The start and stop records for the same task must carry matching values, so a reader can join them and derive a duration. Two client-side rules protect that join: a client must ensure the values it currently has in flight are not duplicated, and it must not reuse a value until it has sent the stop record for the previous task using it. On the server side the constraint is the opposite — a server must not assume anything about the format of a `task_id`, so treat it as an opaque string, never as a counter or a timestamp. Beside it sit the time arguments: `start_time` and `stop_time` in seconds since the epoch, UTC assumed unless a `timezone` argument says otherwise, and `elapsed_time` for the duration.

code

pseudocode · 15 lines
pseudocode
// start record, sent when the shell task begins
flags = TAC_PLUS_ACCT_FLAG_START
args  = [ "service=shell",
          "task_id=8817",
          "start_time=1758248400",
          "timezone=UTC",
          "priv-lvl=15" ]

// stop record for the SAME task, sent when it ends
flags = TAC_PLUS_ACCT_FLAG_STOP
args  = [ "service=shell",
          "task_id=8817",        // must match the start record
          "stop_time=1758249137",
          "elapsed_time=737",
          "reason=idle timeout" ]

go deeper

for a junior

Recall that task_id is the value that makes a start record and a stop record one event, and that the two must match for the pair to mean anything.

for a middle

Explain who each rule binds: the client must avoid duplicate active values and must not reuse one before sending the stop, while the server must not assume any format at all.

for a senior

Demonstrate how you read a trail with broken correlation — an unmatched start is an open interval, a repeated identifier makes both intervals untrustworthy, and clock behaviour shows up as elapsed_time disagreeing with the subtraction.

for a principal

The angle is that correlation quality is entirely a client-side property of a fleet you may not control, so any audit programme built on these records inherits the weakest device's identifier discipline.

## The problem this argument solves A TACACS+ accounting trail is a stream of independent records. Each one travels in its own TACACS+ session with its own `session_id`, and those sessions are not the join key — a start record and the stop record that closes it are two separate exchanges, often minutes or hours apart, possibly over different TCP connections to different servers. Something inside the record body has to say *these two pages describe one job*. That something is the `task_id` argument. Be careful with the name. The published corpus uses the same token for orchestration task identifiers in unrelated tooling topics; here it means one thing only — the TACACS+ accounting argument that correlates a start record with its stop. ## The rules, and who each one binds 1. **Matching** — the start and stop records for the same event must carry the same `task_id` value. This is what turns two records into an interval. 2. **No duplication while active** — a client must ensure that the values it currently has in flight are not duplicated. Two live tasks sharing a value produce a trail nobody can untangle. 3. **No reuse before the stop** — a client must not reuse a value until it has sent the stop record for the task that was using it. A device that recycles a small pool of identifiers after a reload is the classic way this rule gets broken. 4. **No assumptions about format** — a server must not assume anything about the format of the value. It is an opaque token, and a server that parses it as a counter, a timestamp or a globally unique identifier is reading meaning that is not there. Rules 1 to 3 bind the **client**, which is the network device. Rule 4 binds the **server**. That split matters in an interview: the uniqueness guarantee is only ever as good as the device that mints the values, and the server is explicitly forbidden from compensating by inferring structure. ## The time arguments beside it | Argument | What it carries | |---|---| | `start_time` | the time the task began, in seconds since the epoch | | `stop_time` | the time the task ended, in seconds since the epoch | | `elapsed_time` | how long the task ran | | `timezone` | the zone to read the times against | The default reading for the time values is **UTC unless a `timezone` argument accompanies them**. That default is why a reviewer comparing a device record against a wall-clock alarm at 02:40 must first establish which zone each side is speaking; the record itself is unambiguous only when it says so. `elapsed_time` is not merely `stop_time` minus `start_time` restated for convenience. It is the device's own statement of duration, and where a device's clock stepped mid-task the two derivations disagree — which is itself a useful signal, and the reason a system-accounting record can report a clock_change event. ## Reading a trail with these fields - Join on `task_id` first, not on username and not on timestamp proximity. - An unmatched start means an open interval, not a phantom event. - An unmatched stop means the start was lost, not that the task began at the moment you first saw it. - Two closed intervals sharing a `task_id` means the minting rule was broken somewhere on the client side, and neither interval can be trusted to be the one you want. ## The ordering detail that trips implementations Accounting arguments must precede any authorization arguments that appear in the same packet. A reader hand-parsing a capture and expecting `task_id` at the end of the argument list will often be looking in the wrong place, and an implementation that appends its accounting arguments after authorization ones is emitting a packet that does not follow the specification even though every individual argument spells correctly. The overall lesson for an interview answer is that correlation in TACACS+ accounting is **explicit and client-generated**. There is no server-side sequence number, no session-level join, and no derivation from timestamps: if the device did not mint a sound `task_id`, the trail does not correlate, and nothing downstream can repair that.

  • Why can a reader not correlate a start and a stop record using the `session_id` in the header?
    Because a TACACS+ session is a single exchange. The start record is one accounting exchange with its own `session_id` and the stop record is another, so the two headers carry different values. Correlation lives in the body, in `task_id`, precisely because the header cannot provide it.
  • What time base do `start_time` and `stop_time` use?
    Seconds since the epoch, read as UTC unless a `timezone` argument accompanies them. `elapsed_time` states the duration directly, which is worth carrying because a device whose clock stepped during a task gives a different answer by subtraction.
  • A device is reloaded and starts minting task_id values from the beginning of its range again. What breaks?
    Reuse before the stop record was sent. Tasks that were open across the reload can now collide with new ones, so a reader joining on `task_id` may pair a start from before the reload with a stop from after it and report an interval that never happened.

A dispatch docket number written on both the outgoing and the returning copy of one job sheet. The number means nothing on its own — it is not a date, not a route, not a rank — it only asserts that these two pages describe the same job.

saying these in an interview costs you the question

  • Says the session_id in the header links start and stop records
  • Treats task_id as a globally unique value across every device
  • Parses task_id as a timestamp or an incrementing counter
  • Assumes start and stop timestamps are in the device's local zone
  • Thinks a value may be reused as soon as the task ends