skip to content

In a TACACS+ authorization REPLY, what does PASS_ADD tell the network device to do that PASS_REPL does not?

level: seniorimportance: must knowfreq 48%

answer

  1. both statuses mean yes
  2. the difference is whose arguments survive
  3. add layers, replace overwrites
  4. arg_cnt of 0 approves unmodified
  5. a silent replacement still logs as success

basics

~20 s

PASS_ADD keeps the device's own arguments and applies any returned ones in addition, so an arg_cnt of 0 approves the request exactly as sent. PASS_REPL obliges the device to discard what it sent and use the returned arguments instead.

solid answer

~40 s

Both are a yes, and they differ on whose arguments survive. `TAC_PLUS_AUTHOR_STATUS_PASS_ADD := 0x01` says the arguments in the REQUEST are authorized and any arguments in the REPLY apply **as well** — so a reply with `arg_cnt` of 0 is the plain approval of the request unmodified. `TAC_PLUS_AUTHOR_STATUS_PASS_REPL := 0x02` says the device **MUST use the returned argument-value pairs instead of the ones it sent**. That makes PASS_REPL the way a server imposes its own parameters on a shell — an `idletime`, a `timeout`, a `priv-lvl` — and it makes PASS_REPL a poor way to say a simple yes, because whatever the reply carries is now the whole set the device acts on.

code

pseudocode · 13 lines
pseudocode
AUTHOR REQUEST (seq_no = 1)
  arg_1 = "service=shell"
  arg_2 = "cmd="

# case A - approval plus additions
AUTHOR REPLY  status = TAC_PLUS_AUTHOR_STATUS_PASS_ADD  (0x01)
  arg_1 = "idletime=10"
  # device keeps service=shell and its own defaults, adds idletime

# case B - approval by substitution
AUTHOR REPLY  status = TAC_PLUS_AUTHOR_STATUS_PASS_REPL (0x02)
  arg_1 = "idletime=10"
  # device drops what it sent; idletime=10 is now the whole set

go deeper

for a junior

Learn that there are two pass statuses, not one, and that both mean the command or session is authorized.

for a middle

Explain argument ownership: PASS_ADD layers the returned pairs onto the device's, PASS_REPL substitutes them, and arg_cnt of 0 on PASS_ADD is the plain yes.

for a senior

Diagnose from a capture — read the status first, then diff sent against returned — and recognise that a replacement can silently strip parameters while logging as success.

for a principal

Decide what a device-admin server is allowed to impose at all: every parameter it replaces is one the device's own configuration no longer governs, across the whole fleet.

## Two ways to say yes A TACACS+ authorization REPLY has five statuses, and two of them are approvals. The distinction between them is not about how emphatic the yes is; it is about **which set of argument-value pairs the device acts on afterwards**. | status | value | the device's arguments | the server's arguments | |---|---|---|---| | `TAC_PLUS_AUTHOR_STATUS_PASS_ADD` | `0x01` | kept | applied in addition | | `TAC_PLUS_AUTHOR_STATUS_PASS_REPL` | `0x02` | discarded | used instead | ## PASS_ADD PASS_ADD says: the arguments you sent are authorized, and any arguments I am returning apply as well. Two consequences follow. - A reply with **`arg_cnt` of 0** is the ordinary, unadorned approval — run the request exactly as you described it. Most command authorizations that simply mean "yes" look like this. - A reply with arguments is an approval *plus* additions. For a session-based shell authorization that is how a server supplies the parameters the device did not ask about — a `priv-lvl` to assign, an `idletime`, a `timeout`, an `autocmd`. ## PASS_REPL PASS_REPL says: the request is authorized, but **use these arguments in place of the ones you sent**. The device must not merge; the returned list is now the operative list. This is the server rewriting the request rather than annotating it. On a session-based shell authorization that is a natural thing to want — the server is provisioning the session and has a complete view of what it should look like, so replacing is cleaner than adding. On a **command** authorization the same rule still applies, and it is sharper than most people expect: whatever `cmd` and `cmd-arg` values come back are what the device is obliged to work from. A server that returns a different command has not commented on the operator's command; it has substituted one. ## Where this bites in production Picture a broadcaster's contribution-circuit routers. An engineer opens a session during a live feed and finds it drops after a few minutes of thinking time, or comes up at a level that refuses a command they hold every day. The cause is almost always here: the server answered the shell authorization with PASS_REPL and a short argument list, the device honoured the list *instead of* its own configured defaults, and everything the list omitted simply is not in force. The same reply sent as PASS_ADD would have left the device's defaults standing and layered the server's two arguments on top. The diagnostic habit worth having: 1. Capture the authorization REPLY for the failing session and read its **status** before reading anything else. 2. If it is PASS_REPL, list what the device sent and what came back — the difference is exactly what the session lost. 3. If it is PASS_ADD with `arg_cnt` of 0, the authorization is not your problem; the request was approved as sent. ## The other three statuses, for contrast - `TAC_PLUS_AUTHOR_STATUS_FAIL := 0x10` — processing completed and the answer is no. - `TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11` — processing did not complete on the server. **No argument value in the reply has any relevance and all of them MUST be ignored.** It is not a denial. - `TAC_PLUS_AUTHOR_STATUS_FOLLOW := 0x21` — the device is being pointed at another server, and `arg_cnt` MUST be 0. The pairing to keep straight is that PASS_ADD and PASS_REPL differ over argument *ownership*, while FAIL and ERROR differ over whether a decision was reached at all. Collapsing either pair loses something the protocol deliberately separated. ## Why it is a senior question Because both statuses read as success in a log line, and the failure they produce shows up somewhere else entirely — a shell with the wrong idle timeout, a session at an unexpected level, a parameter the device was sure it had configured. Knowing that a *successful* authorization can silently replace the device's own view of the session is the part that only comes from having chased one.

  • What does a PASS_ADD reply with `arg_cnt` of 0 mean?
    That the request is authorized exactly as the device sent it, with nothing added. It is the plainest yes the protocol has, and it is what a command authorization that simply permits the command normally looks like.
  • Can a device merge the returned arguments into its own under PASS_REPL?
    No. PASS_REPL obliges the device to use the returned pairs **instead of** the ones it sent. A device that merges is not implementing the status, and the resulting session carries parameters the server did not sanction.
  • Why is FAIL not simply a third kind of pass status with an empty list?
    Because FAIL is a different axis. PASS_ADD and PASS_REPL both authorize and differ over argument ownership; FAIL is a completed decision to refuse. And ERROR sits on yet another axis again — no decision was reached, so the reply's arguments MUST be ignored.
  • What should a server send when it means nothing more than yes?
    PASS_ADD with `arg_cnt` of 0. Sending PASS_REPL to mean yes hands the device a replacement set — and if that set is empty or partial, the device loses the parameters it was carrying, which surfaces as a session that behaves unlike every other one.

Two ways an approver hands back a request slip: initialled with a couple of extra conditions written in the margin, or torn up and replaced with the approver's own slip that you must submit instead.

saying these in an interview costs you the question

  • Says PASS_REPL is a stronger or more trusted pass
  • Merges the returned arguments under PASS_REPL
  • Reads an empty argument list on PASS_ADD as a refusal
  • Treats FAIL and ERROR as two words for the same outcome
  • Assumes a successful status means the session is as the device configured it