skip to content

In TACACS+ per-command authorization, which side decides whether a typed command may run, and which side stops it?

level: juniorimportance: should knowfreq 38%

answer

  1. policy lives off the box
  2. client means the device here
  3. one question, one answer
  4. no CONTINUE in this exchange
  5. server decides, device applies

basics

~20 s

The device-administration server decides; the network device enforces. The device suspends the typed command, sends a TACACS+ authorization REQUEST describing it, and then runs or refuses it according to the single REPLY that comes back.

solid answer

~40 s

In TACACS+ the *client* is the network device itself, not the human. With command authorization in force the device holds no opinion about what may be typed: for each command it builds an authorization REQUEST (packet type `TAC_PLUS_AUTHOR := 0x02`), describes the command as argument-value pairs, and waits. The device-administration server evaluates policy and answers once. The exchange is exactly two packets — REQUEST then REPLY, `seq_no` 1 and 2 — with no CONTINUE and no way for the server to prompt. The server decides and the device enforces: the server never executes anything on the box, and the device runs or refuses the command purely on the returned status.

code

pseudocode · 14 lines
pseudocode
operator types a command

device:
  suspend the command
  send AUTHOR REQUEST   (seq_no = 1, type = TAC_PLUS_AUTHOR)

server:
  evaluate policy for this user and these arguments
  send AUTHOR REPLY     (seq_no = 2)

device:
  if status is PASS_ADD or PASS_REPL: run the command
  if status is FAIL:                  refuse the command
  if status is ERROR:                 no decision was reached

go deeper

for a junior

Remember the direction and the vocabulary: in TACACS+ the client is the network device, the server decides, and the device applies the answer. One command, one REQUEST, one REPLY.

for a middle

Be able to name the packet type and the five reply statuses, and to explain why FAIL and ERROR are different answers rather than two words for failure.

for a senior

Show that you know what the device does with a reply it cannot act on, and that the single-REPLY shape means every input to the decision must already be in the REQUEST.

for a principal

Frame it as where policy lives: centralising the decision buys one place to change an estate's rules and creates a dependency on reaching that place from every box.

## Who the client is here In TACACS+ the word **client** means the network device — a router, a switch, a terminal server — and not the human at the keyboard and not a piece of software. RFC 8907 defines the client as any device that initiates TACACS+ protocol requests. Getting this straight first is what makes the rest of the branch legible: the operator types, but the **device** is the party that speaks the protocol. Per-command authorization is the arrangement in which that device holds **no opinion of its own** about which commands an operator may run. Each time the operator presses Enter, the device suspends the command, describes it to a central **device-administration server** as a set of argument-value pairs, and waits for one answer. The server evaluates its policy and replies. The device then runs the command, or refuses it and prints a refusal to the operator. ## The decision and the enforcement sit in different places - The **server decides.** It holds the rules, it is told what was typed, and its reply *is* the decision. - The **device enforces.** It is the only party with a command line, a configuration and the ability to execute anything. The server never runs a command on the box and has no session there. - Neither side does the other's job. A device configured to authorize a service does not consult a local rule set for it, and a server that answers does not reach into the device. That split is the point of running device administration this way. Policy lives in one place for a whole estate: change what an on-call engineer may type on a broadcaster's contribution-circuit routers and the change is live on every router at once, with no configuration push and no per-box account list to reconcile afterwards. ## One question, one answer An authorization exchange is exactly two packets — a REQUEST from the device and a REPLY from the server — carried in a TACACS+ session of their own, with packet type `TAC_PLUS_AUTHOR := 0x02` and `seq_no` running 1 then 2. There is no CONTINUE packet in authorization and no way for the server to ask the operator anything; the authentication conversation next door can run several packets, but this one cannot. Everything the server needs must already be in the single REQUEST, and everything the device learns arrives in the single REPLY. ## What can come back | REPLY status | value | what the device does | |---|---|---| | `TAC_PLUS_AUTHOR_STATUS_PASS_ADD` | `0x01` | runs it, applying any returned arguments in addition to its own | | `TAC_PLUS_AUTHOR_STATUS_PASS_REPL` | `0x02` | runs it, but with the returned arguments in place of the ones it sent | | `TAC_PLUS_AUTHOR_STATUS_FAIL` | `0x10` | refuses: the server processed the request and the answer is no | | `TAC_PLUS_AUTHOR_STATUS_ERROR` | `0x11` | has no decision: processing did not complete, and every returned argument value MUST be ignored | | `TAC_PLUS_AUTHOR_STATUS_FOLLOW` | `0x21` | is being pointed at a different server; `arg_cnt` MUST be 0 | The two that get collapsed in conversation are FAIL and ERROR. **FAIL is an answer** — the server thought about it and said no. **ERROR is the absence of an answer**, and the device must not read it as a refusal; what the device then does with an undecided request is a device-side configuration matter rather than something the reply settles. ## What this exchange is not 1. **Not authentication.** The operator's identity was established earlier, in its own exchange. Authorization assumes that identity and asks only whether this command may run. 2. **Not a record of what happened.** Nothing here says the command succeeded — at the moment the server answered, the command had not run. 3. **Not a permission for the whole session.** With command authorization in force, each typed command produces its own REQUEST and its own REPLY, so a long maintenance session is a long series of two-packet exchanges. ## Why an interviewer opens here Because a candidate who has the direction right can be asked anything else on the branch, while one who has it backwards produces sentences that are fluent and entirely wrong: a server that executes the command, a device that keeps a local allow-list and only asks on a miss, an ERROR that denies. Say the direction out loud — the server decides, the device applies — and the rest of the material follows from it.

  • Can a TACACS+ authorization exchange ever run to more than two packets?
    No. Authorization is a REQUEST and a REPLY, `seq_no` 1 and 2, and no CONTINUE packet exists for it. A `TAC_PLUS_AUTHOR_STATUS_FOLLOW := 0x21` reply points the device at a different server, but acting on that means opening a fresh session with its own REQUEST — it does not extend this one.
  • What has the device learned when the REPLY is `TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11`?
    Nothing about the command. ERROR says the server's processing did not complete, so no argument value in the reply has any relevance and all of them MUST be ignored. It is not a denial — treating it as one is the classic misreading, and it is the reason the specification separates ERROR from FAIL at all.
  • If the operator already authenticated, why ask again for every command?
    Authentication establishes who is at the keyboard once. Per-command authorization asks a different question each time — may *this* command run — which is what lets one operator reroute a circuit while another, authenticated exactly the same way, is refused a reload on the same box in the same session.

saying these in an interview costs you the question

  • Says the device-administration server executes the command
  • Thinks the device keeps a local command list and only asks on a miss
  • Expects a multi-packet negotiation like the authentication exchange
  • Reads an ERROR reply as a denial of the command
  • Believes authorization re-checks the operator's password