A read-only account needs to pass three separate checks: it can log in, it can read the information required for the job, and it cannot make the changes your requirements prohibit.
A successful login proves only part of that.
Adapted from my original Japanese article, with AI-assisted translation and editing.
I'm Goda, a network engineer in Japan. My Japanese blog has recently drifted into TFT and experimenting with AI, so this is also an attempt to remember what my job is.
In the previous article, I covered what to check when Cisco ISE Command Sets do not work as expected.
This time, the question is what we should put in a test plan before signing off on read-only access.
1. Turn “read-only” into three testable requirements
You sign in with the account. The management screen opens. You write “Pass.”
So far, so straightforward.
But can that account read the logs needed to investigate an incident? And can it really not change the settings it is supposed to leave alone?
| Check | Example acceptance criterion |
|---|---|
| Can log in | A management session starts using the intended authentication source, user, and permissions. |
| Can read what is needed | The account can view the required status and logs for the resources it is allowed to access. |
| Cannot make prohibited changes | A valid prohibited operation is rejected by the applicable permission control, and the target remains unchanged. |
These are examples for designing tests, not results from a device test. Choose actual operations and acceptance criteria for your product and requirements.
“Nothing could be changed” is not sufficient if the account also cannot read the logs that its operator needs. Likewise, being able to read logs does not establish that changes are blocked.
TACACS+ separates authentication, authorization, and accounting. A successful authentication record therefore cannot, by itself, establish which subsequent operations were permitted. RFC 8907, section 1
2. Define what the account may read and what it must not do
“It is a read-only user. Should I just try some show commands?”
First, define the job the account is intended to support.
Before testing, decide:
- Which devices or resources are in scope.
- Which status, logs, and configuration information the operator needs.
- Which information or resource scopes must remain inaccessible.
- Which operations are prohibited, such as configuration changes, saving changes, restarting, or user administration.
- Which management interfaces are actually provided: CLI, GUI, or API.
Read-only does not necessarily mean permission to read every piece of information. A read operation can still expose sensitive information or impose processing load.
Translate the requirement into operations before deriving tests from the role name.
“Can view the status and necessary logs of the assigned resources” gives us a more useful scope than “has read-only access.”
3. Do not try a dangerous operation because it “should be denied”
This needs to come before the negative tests:
For tests involving configuration changes, saving, restarting, or other potentially disruptive operations, establish the impact and recovery procedure if the operation succeeds. Use a suitable test environment. Do not try a dangerous operation on a production device on the assumption that it will be rejected.
We are testing whether the permission control is correct. If it is wrong, the action may go through.
If the device restarts at that moment, we will certainly have a test result. We will also have another problem.
Before testing a change, identify the test resource, possible impact, recovery method, and stop conditions. If an operation cannot be tested safely, record why it was not performed and what remains unverified.
4. An error message does not automatically mean “Pass”
You attempt a prohibited operation. An error appears.
That looks promising. But what if you simply mistyped the command?
A syntax error does not prove that authorization would reject a valid operation.
The following are illustrative interpretations, not actual test results:
| Observation | What the evidence supports |
|---|---|
| A valid operation is rejected for insufficient permissions, and the target is unchanged | Denial was verified for that operation under those test conditions. |
| The input produces a syntax error | The attempted operation was invalid. Permission-based denial remains unverified. |
| The connection drops before execution | There is a connection or processing problem. This is not evidence of authorization denial. |
| A change button is hidden | That screen hides the button. Other management paths remain unverified. |
| Authorization permits the operation, but execution fails for another reason | The operation was not stopped by the permission control. |
If button visibility is itself a requirement, testing it can satisfy that requirement. It does not establish that the same change is impossible through another interface.
Separate what failed from why it failed.
Use an operation valid for the product, identify the reason for rejection, and check the target's state. “An error appeared” is too broad an acceptance criterion.
5. “Cannot deploy” and “cannot edit” are different restrictions
Cisco NDFC provides a useful documented example.
In the NDFC 12.2.2/12.2.3 guide:
- Network Operator can view configuration information but cannot change expected switch configurations or deploy them.
- Network Stager can prepare configuration changes inside NDFC but cannot deploy them to switches.
The Stager deployment restriction includes deployment-related Web UI and REST API actions. These are NDFC application roles; do not assume that a similarly named device role behaves identically. Cisco NDFC role documentation
A result of “could not deploy to the switch” does not tell us whether the user could edit configuration intent inside the management system.
Editing in the interface, saving in the management system, and applying to a device may be separate operations. Test the stages your requirements prohibit.
This example is scoped to the documented NDFC versions. Do not transfer it unchanged to another product or release.
6. Connect the operation, permission decision, and actual outcome
“Changes blocked: OK” is not a useful record when someone later asks what happened.
Which operation? Which user? Did a permission check reject it? Was the target actually unchanged?
Keep these pieces of evidence connected:
- Target, management interface, user, and applied permissions.
- Exact operation and arguments, execution time, and device or UI response.
- The corresponding authorization decision, or evidence of the device's own permission enforcement.
- The target-state check and the location of the supporting evidence.
If the device requests per-command authorization from ISE, trace the corresponding request and authorization result.
If the device enforces an assigned role locally, check the assigned role and the device's execution results and audit records.
ISE provides separate TACACS authentication, authorization, accounting, and command-accounting reports. Choose records appropriate to the control method and the accounting actually configured. Cisco ISE 3.5: Monitor Device Administration Activity
Do not make “every operation appears in ISE command authorization logs” a universal acceptance criterion for every product. Do not assume that every denied operation produces a command-accounting record either.
Correlate the target and operation as well as the time and username.
Here is a fictional example of a test record:
Target: Lab resource A, accessed through the GUI with the read-only test account.
Operation: Attempt a valid change to a setting that the requirements prohibit this account from changing.
Result: Rejected for insufficient permissions. Verified that the setting remained unchanged.
Evidence: The operation's UI response, the corresponding audit record, and the before/after setting checks.
Scope of conclusion: This user, resource, interface, and operation. CLI and API checks are separate test items.
For an actual record, fill in the timestamp, evidence IDs, exact setting, and other identifying details required by the test plan.
7. Keep untested scope out of the pass result
A CLI test is not a GUI test or an API test.
For each management path that is provided and used, verify the necessary read operations and the prohibited actions. You do not need to enable an unused management interface just to test it.
If permissions have recently changed, record the session state too. Whether a permission change affects an existing session, and when, depends on the product. Keep those results distinct from tests using a new session.
Finally, do not turn every empty cell into “OK.”
- Not performed: Record the reason and the conditions needed to run it.
- Not applicable: Explain why the item is outside the relevant scope.
- Inconclusive: Record the missing evidence needed for a decision.
I want the test plan to show how far the verification actually goes.
Can log in. Can read what is needed. Cannot make prohibited changes.
Separating those three questions gives us something concrete to write after “Read-only login: successful.”
A sample worksheet
I have published a free TACACS+ test checklist sample in Japanese for turning these ideas into test items.
It covers five basic CLI administration checks. It is a test-design template that has not been validated on actual devices, not a ready-made certification of your environment. Adapt the operations, acceptance criteria, and evidence to the target equipment. GUI and API tests need separate design.
For troubleshooting restrictions that are not behaving as intended, see Cisco ISE Command Sets Not Working? Check Authorization Before Your Deny Rules.
The examples in this article were created for explanation and are not reported results from tests performed on actual equipment. Product-specific statements are limited to the versions identified in the linked documentation.
Top comments (0)