skip to content

A device-administration server answers a TACACS+ authentication START with status ERROR rather than FAIL — what changes for the network device?

level: seniorimportance: must knowfreq 44%

answer

  1. one is a verdict, one is silence
  2. completed processing versus incomplete
  3. ERROR equals unreachable, by obligation
  4. no cause code travels with ERROR
  5. RESTART is also not a verdict

basics

~20 s

FAIL is an answer: processing completed and the login is refused. ERROR is the absence of one — the server could not complete, the device has no result to apply, and it must behave as if that server had never been reachable.

solid answer

~50 s

`TAC_PLUS_AUTHEN_STATUS_FAIL` means the server did its work and the answer is no. The operator is refused, and the refusal is authoritative. `TAC_PLUS_AUTHEN_STATUS_ERROR` means something in the server's processing did not complete — it makes no claim about the operator at all. The device cannot apply it as a verdict and MUST behave as if that host could not be contacted, which is the same position it is in when a connection is refused or times out. Collapsing the two is the most consequential mistake on this branch in both directions: treating ERROR as FAIL turns a server outage into a wall of authoritative refusals, and treating FAIL as ERROR turns a refused operator into one whose login simply had no answer. What the device does next is a deployment choice; what the status means is not.

code

pseudocode · 15 lines
pseudocode
on AUTHEN REPLY from device-admin server:
    if status = TAC_PLUS_AUTHEN_STATUS_PASS
        admit the operator
    else if status = TAC_PLUS_AUTHEN_STATUS_FAIL
        refuse the operator          # an answer: stop here
    else if status = TAC_PLUS_AUTHEN_STATUS_ERROR
        mark this server as unanswered   # not an answer
        continue as if it had not been reachable
    else if status = TAC_PLUS_AUTHEN_STATUS_RESTART
        if RESTART is implemented
            begin a new sequence
        else
            refuse the operator      # required fallback
    else if status = TAC_PLUS_AUTHEN_STATUS_FOLLOW
        refuse the operator          # deprecated redirection

go deeper

for a junior

Learn the pair as a contrast: one status means the far end said no, the other means the far end did not manage to say anything. They are not two flavours of the same outcome.

for a middle

Explain the obligation, not just the meaning: on ERROR the device must behave as if that host could not be contacted, so it holds no verdict and no claim about the operator.

for a senior

Show the failure you have seen: a server that returns ERROR while an implementation treats it as FAIL turns its own outage into a fleet-wide wall of authoritative refusals, and the diagnosis goes to credentials instead of to the server.

for a principal

The judgment is how much of your device estate you trust to read that byte correctly. Where you cannot verify it, the safer assumption is that some devices refuse rather than fall through, and your availability planning has to carry that.

## Two words that sound alike and are not Every authentication REPLY carries a status byte, and two of its values are routinely read as the same thing. They are opposites in a way that matters: - **`TAC_PLUS_AUTHEN_STATUS_FAIL`** — the server's processing **completed**. It evaluated the request and the answer is no. This is a decision about the operator. - **`TAC_PLUS_AUTHEN_STATUS_ERROR`** — the server's processing **did not complete**. It makes no claim about the operator whatsoever. The device holds no result. The obligation the specification places on the device follows directly: on ERROR it MUST behave as though the server could not be contacted. Not "as though the login was refused" — as though nothing answered. ## Why the distinction has teeth Read the two failure directions side by side: | | Server returns FAIL | Server returns ERROR | |---|---|---| | Did the server evaluate the operator? | Yes | No | | Is the outcome a claim about this operator? | Yes | No | | Equivalent to an unreachable server? | No | Yes | | Device treats it as an answer? | Yes | It must not | And read the two ways an implementation gets it wrong: - **ERROR read as FAIL.** A server that has lost its identity store, or is out of memory, or hit an internal timeout, now produces authoritative refusals. Every operator is told their credential is wrong. Nobody suspects the server, because the device is reporting a clean decision. On a vessel with no one aboard who can log in locally, a self-inflicted outage looks exactly like everyone forgetting their password at the same moment. - **FAIL read as ERROR.** The opposite and rarer inversion. A genuine refusal is now treated as no answer at all, and the device carries on as though the server had been silent — which is how an operator the server has just refused ends up being admitted by whatever the device tries next. ## The status is not a diagnosis ERROR carries no machine-readable cause. The device cannot tell from the status whether the server was overloaded, misconfigured, unable to reach its identity store or simply out of a resource it needed. That is deliberate: the device is not being asked to reason about the server's internals, only to stop treating this host as a source of answers for this attempt. Anyone diagnosing a rash of ERRORs is doing it from the server's own records, not from what the device saw. ## Where the neighbouring subjects begin Two boundaries are worth stating plainly, because the ERROR case runs right up to both: - **What the device does after an ERROR** — which server it consults next, in what order, whether a locally held account is consulted at the end of that order, and what happens when nothing answers at all — is a deployment and device-configuration subject, not a protocol one. The protocol's contribution is precisely the sentence "behave as if the host could not be contacted". - **Whether the exchange should have been attempted over that path at all** — the transport, and what protects the body along it — belongs to the wire-format and payload-protection subjects. ## The other statuses that are not answers either ERROR is not alone in being a non-answer, and knowing the set is what separates a middle answer from a senior one: - `TAC_PLUS_AUTHEN_STATUS_RESTART` says the `authen_type` the device chose is unacceptable and the sequence may begin again. It is not a verdict on the operator either. A device that does not implement RESTART MUST process it as FAIL — note that this is one of the few places the specification converts a non-answer into a refusal, and it does so explicitly rather than by accident. - `TAC_PLUS_AUTHEN_STATUS_FOLLOW` is the deprecated redirection mechanism. Servers MUST deprecate it; clients SHOULD treat it as FAIL. Again, the strength matters: the obligation on the server is stronger than the one on the client. - The three `GET` statuses — `GETUSER`, `GETPASS`, `GETDATA` — are not answers in a different sense: they are requests for another turn, and the sequence is still live. What unites the good answers to this question is a single sentence you should be able to say without hedging: **FAIL is a decision, ERROR is the absence of a decision, and a device that cannot tell them apart will misreport its own outages as everyone else's mistakes.**

  • What breaks when an implementation collapses ERROR into FAIL?
    A server-side outage stops looking like an outage. Every operator is refused with an authoritative no, the device consults nothing else because it believes it has an answer, and the failure is attributed to credentials rather than to the server. The device has converted its own lack of information into a claim about people.
  • Does an ERROR tell you whether the server was overloaded, misconfigured or unable to reach its identity store?
    No. The status carries no cause and the exchange has no field for one. From the device's side, ERROR means only "no result from this host". Establishing why takes the server's own records; the protocol deliberately keeps the device out of that reasoning.
  • Is RESTART an answer about the operator?
    No — it says the `authen_type` the device chose is unacceptable and the sequence may begin again, typically with a different type. It is a statement about the request's form. The one twist is that a device which does not implement RESTART MUST process it as FAIL, so a non-answer becomes a refusal by explicit rule.

saying these in an interview costs you the question

  • Says ERROR means the credential was wrong
  • Treats ERROR and FAIL as interchangeable failure codes
  • Expects a cause code to accompany ERROR
  • Thinks FAIL means the server was unreachable
  • Assumes ERROR always indicates a shared-secret mismatch
  • Believes RESTART is a verdict about the operator