A TACACS+ rollout needs more than a successful login. Test what happens when one server is unavailable, when none can answer, and when the service returns. For each state, check who authenticated the user, what the user could do, and what evidence was recorded.
That last part is easy to miss. “I got a prompt” does not tell us which server answered—or whether a local account was used instead.
I'm Goda, a network engineer in Japan. This article develops the outage-testing questions from my Japanese TACACS+ material. The examples below are illustrative test designs, not reported results from a customer environment.
The focus is device administration through an SSH CLI. Product behavior depends on the device, software release, AAA configuration, and management path.
Start with an expected outcome for each failure state
Before interrupting anything, write down the behavior your design requires.
The following is an example policy, not a universal TACACS+ requirement. In this example, ordinary users rely on centralized authentication and a separate emergency account is available through a deliberately configured local recovery path.
| Test condition | Expected result in this example | Evidence to collect |
|---|---|---|
| Both servers available; valid ordinary account | Normal centralized access with the intended permissions | Device response, server that handled the request, authorization and accounting evidence |
| First server unavailable; second available | Access through the remaining server, within the agreed time limit | Failure condition, elapsed time, request handled by the remaining server, resulting permissions |
| All configured servers unreachable; ordinary account | No unintended local access | Device response and evidence explaining the authentication outcome |
| All configured servers unreachable; designated emergency account | The approved recovery path works with only its intended permissions | Local authentication evidence, role or privilege, recovery-operation results, available audit evidence |
| Central service restored | New sessions use the intended normal path and normal controls work again | Authentication, permitted and prohibited operations, accounting, removal of temporary test changes |
If your design intentionally has no local fallback, do not add one just to make the fourth row pass. Define how authorized recovery is supposed to work and test that arrangement.
Also, “first server” means the server the device is expected to try under the recorded starting conditions. Do not assume that every implementation always selects a server with the label “primary.”
A rejection is different from a server that cannot answer
Do not simulate a server outage by entering the wrong password.
A server can be fully reachable and deliberately reject authentication. A timeout means no usable response arrived within the relevant limit. A protocol error is another condition again.
RFC 8907 distinguishes a completed negative decision from an incomplete exchange: a FAIL result is applied as a decision, while an ERROR must be treated as though the server could not be reached. Available alternative methods may then be used. The details of redundancy, fallback, and timeouts are implementation-specific. RFC 8907, section 4.4
That gives us separate test items:
- A validly formed login request that receives an explicit authentication rejection.
- A request whose intended server does not respond.
- An error condition, if that condition is part of the test scope.
For each one, record what actually happened. Do not label every failed login “server down,” and do not assume every failure should move on to a local account.
Check the target platform's documented method-list behavior and your configured policy before writing the expected result.
A one-server outage should prove which server took over
Suppose the design has two TACACS+ servers and access should continue when either one is unavailable.
“I disconnected one server and could still log in” is incomplete evidence. The device might have used the other server, a local account, or an existing session that never performed a new login.
A useful test sequence is:
- Record the starting configuration and confirm normal access.
- Establish the approved failure condition for one server.
- Start a new management session with the intended test account.
- Identify which authentication source handled that attempt.
- Check the resulting permissions and relevant records.
- Record the elapsed time and compare it with the acceptance limit chosen before the test.
- Restore the starting conditions before testing the opposite direction.
Choose the failure mechanism carefully. Dropping traffic, rejecting a connection, and stopping a service can produce different observations. Record which condition you created instead of calling all of them the same outage.
Existing sessions can be a separate test item. Whether an already-open session can run its next command may depend on a different authorization exchange.
Local login is only the first part of emergency access
An emergency account is useful only if it supports the recovery work it was designed for.
Check these questions separately:
- Did local authentication succeed?
- Was a management session actually established?
- Which role or privilege was applied?
- Could the account perform the explicitly approved recovery operations?
- Were operations outside that scope controlled as designed?
- What record of the activity remained available?
TACACS+ treats authentication, authorization, and accounting as separate functions. Passing one stage does not establish the outcome of the others. RFC 8907, section 1
There is a concrete platform example in the Nexus 9000 NX-OS 10.4(x) guide. Command authorization has its own fallback configuration. Local command authorization is used only when the configured server groups fail to respond and local fallback has been configured; without that fallback, authorization fails. Console command authorization is configured separately as well. Cisco NX-OS 10.4(x): Configuring TACACS+
This is why a locally accepted password can still leave you unable to do the intended recovery work. Use the documentation for the actual product rather than copying NX-OS behavior to another platform.
Decide how to test safely before creating the outage
Use a suitable lab or an explicitly approved maintenance procedure. Establish an independent recovery path, define stop conditions, and prepare restoration steps before changing connectivity or AAA behavior.
A session that is already open is not automatically a sufficient recovery path: its next operation may still depend on the service you are about to interrupt.
Prefer harmless operations that demonstrate the required permission boundary. Do not try a restart, deletion, or disruptive configuration change on production equipment merely because the account is supposed to be denied.
For each disruptive test, identify:
- What will be changed or interrupted.
- What could be affected if the assumption is wrong.
- How recovery can be performed if the tested management path fails.
- When to stop, who restores the environment, and what evidence to preserve.
If those conditions are missing, record the item as not performed and state what is needed to run it.
“The server responds again” is not a complete recovery test
Restoring connectivity is a step toward recovery. It does not prove that normal administration has returned.
My suggested recovery checks are:
- New authentication: Start a new session and identify the source that authenticates it.
- Permissions: Repeat a representative permitted operation and a safely designed prohibited-operation test.
- Accounting: Confirm that the expected new activity reaches the intended records.
- Emergency access: Check that its post-recovery behavior matches the design. This does not necessarily mean deleting a deliberately retained emergency account.
- Cleanup: Remove temporary failure-injection settings and verify the resulting configuration.
- Handover: Record remaining gaps and the evidence that supports closure.
Do not require immediate return to a preferred server unless the product and configuration actually promise it. Server reactivation follows platform-specific policies and timers. For example, ASA 9.16 documents different reactivation modes, while NX-OS documents dead-time and probing behavior. Record the chosen settings and observed server selection. Cisco ASA 9.16: TACACS+ Servers for AAA
For ISE, use the report appropriate to the event. Its 3.5 guide lists separate TACACS Authentication, Authorization, Accounting, and Command Accounting reports. A login record does not substitute for command-accounting evidence. Cisco ISE 3.5: Device Administration
Also distinguish new records after restoration from records of activity during the outage. Seeing new records does not prove that every missing event was buffered and resent. If outage-period audit coverage is required, verify that behavior separately or document the approved alternative evidence.
Keep the failed run when the retest passes
Here is a fictional example:
First run: The emergency account passes local authentication, but a required recovery operation fails because its command authorization still depends on the unavailable service.
Judgment: Fail for the emergency-operation requirement. Keep the authentication success as an observation.
Next action: Review and correct the approved recovery design, then repeat the relevant test.
Retest: Add a new result linked to the original failure and the correction. Do not replace the failed row with “Pass.”
This makes the conclusion reviewable: someone can see the original condition, the issue, what changed, and what the next attempt demonstrated.
The same applies when evidence is incomplete. A test with an unexplained error is inconclusive, not automatically a successful denial.
The questions I want the record to answer are simple: Who authenticated the user? What could they do? What was recorded? What proves normal operation has returned?
Optional worksheets: free sample and paid kit
If you want an editable starting point, I publish two resources on note. Both the worksheets and their accompanying material are in Japanese. These are my own products.
- Free sample: five basic TACACS+ administration checks.
- Standard kit: 24 tests covering normal access, failure conditions, emergency access, and recovery. It is a one-time ¥800 purchase at the time of writing, with Excel worksheets, worked examples, a PDF guide, and fictional evidence examples. Purchase and download take place on note.
The kit is a test-design template, not a set of validated device configurations. Adapt the conditions, operations, and acceptance criteria to your equipment. Check the product page for the current price, contents, and usage terms.
For the permission checks discussed here, see my earlier article: Read-Only Access Testing: A Successful Login Is Not Enough.
Prepared with AI-assisted translation and editing of my Japanese material, with the additional protocol and product explanations checked against the official sources linked above.
Top comments (1)
The distinction between a rejection and an unreachable server is the one that gets flattened in almost every rollout test I have seen. "I typed the wrong password and it still let me in via local" is reported as fallback working, when what was actually proven is that a FAIL was applied as a decision — the server answered, it said no, and something downstream decided to keep going anyway. Those are different configurations with different failure modes, and only one of them is the one you want under a real outage.
The evidence column is what makes the matrix useful. Recording which server authenticated, not just that authentication succeeded, is the difference between "failover works" and "the device silently used a local account for three weeks because the first server stopped answering". Accounting records carry that; a prompt does not.
One thing worth adding explicitly: the emergency account's authorization is a separate test from its authentication, and it is the half people skip. A locally accepted password with no local command authorization in place leaves you logged in and unable to run the recovery commands, which is a worse discovery than not getting in at all.