Boss: “No overtime. (But finish the work.)”
Me, a lowly network engineer: “Understood. (Overtime wouldn't be enough anyway.)”
Hi, I'm Goda, the network engineer behind NW Field Memo.
When you work with TACACS+ authorization in Cisco ISE, you come across Command Sets. Put simply, they let you define which commands to allow and which to deny.
My first impression was straightforward:
Create a Command Set for a read-only user → allow the required show commands → select it in the authorization policy → read-only access, done.
It turned out to be less straightforward.
Creating a Command Set does not prove that an operation is being controlled by it.
Here is the order I use to investigate when an ISE Command Set does not restrict an operation as expected.
What does a Command Set actually do?
A Command Set is an authorization result used in ISE Device Administration. It defines permit/deny decisions for commands.
An illustrative policy might allow show and ping, while denying configure and reload. This is a conceptual example, not a complete read-only policy or a configuration to copy into production.
The key dependency is the network device: it must request command authorization from ISE for the operation you want to control.
It is tempting to jump straight to the ISE configuration screen. I certainly did. But first, separate two questions.
“Can I log in?” and “Can I run this command?” are different questions
TACACS+ separates the three parts of AAA:
| Function | The question it answers |
|---|---|
| Authentication | Who are you? |
| Authorization | What are you allowed to do? |
| Accounting | What did you do? |
A successful login with an ISE user does not demonstrate that Command Set authorization works.
A simplified authentication flow looks like this:
User attempts to log in
→ Network device asks ISE to authenticate the user
→ Authentication succeeds
→ User logs in
Command authorization involves another decision:
User enters a command, such as show running-config
→ Network device asks ISE whether that command is allowed
→ ISE returns a permit/deny decision
→ Network device handles the operation
These are simplified flows, not packet traces. The point is that the first successful exchange does not prove the second exchange happened. RFC 8907 defines authentication, authorization, and accounting separately.
Make “the Command Set doesn't work” more specific
These observations are different:
- A prohibited CLI command ran.
- A user could change a setting in the GUI.
- A configuration page opened.
- A change button could be clicked.
- The change was actually saved or applied.
Start by recording what the user did, what should have happened, and what actually happened.
For example:
A read-only user logged in through the CLI. The user entered
configure terminal. It was expected to be denied, but the device accepted it.
That gives you something concrete to trace. Also record the product, OS version, and access method.
Before editing the Command Set, find the authorization request
This is the main point of this article.
When a prohibited command runs, it is tempting to think, “Maybe I wrote the Deny rule incorrectly,” and immediately edit the Command Set.
Before doing that, ask:
Did ISE receive a command authorization request for that operation?
If the operation is not being submitted to ISE for command authorization, rewriting its Command Set cannot control that operation.
A useful sequence is:
- Identify the exact operation being tested.
- Find its corresponding authorization request in ISE.
- Check which authorization policy rule matched.
- Check which Command Sets were selected.
- Then inspect the Command Set rules.
When reproducing an operation, use an authorized test environment and consider what happens if the operation succeeds. The read-only testing section below explains why this matters.
“I cannot find a request” does not immediately mean “unsupported”
An authorization record may be missing from the logs you are looking at. That alone does not prove that the product lacks command authorization support.
Check:
- Whether command authorization is configured on the device.
- Whether you are tracing the same user and session.
- Whether the log type, time range, and filters are correct.
- Whether that access method and operation use command authorization.
“I could not find the log entry” is an observation.
“This product does not support that function” is a conclusion that requires further investigation.
Keeping those separate also makes a TAC case much easier to write.
TACACS Profiles and Command Sets are different, too
A simplified distinction is:
- TACACS Profile: returns session attributes or privilege information for the device to interpret.
- Command Sets: determine whether a requested command is permitted or denied.
Different products may use privilege levels, roles, or vendor-specific attributes. A profile named “Read-Only” is not proof of read-only behavior.
You need to understand how that device interprets the returned attributes and which authorization mechanisms it uses.
I plan to cover privilege levels, roles, and custom attributes separately.
Once the right Command Sets are selected, inspect their evaluation
Suppose the request arrived and the expected policy and Command Sets were selected. Now examine the command and arguments the device actually sent.
In the Cisco ISE 3.5 guide, the Command field uses wildcard matching, while Arguments uses regular expressions.
Do not assume the same expression means the same thing in both fields.
An ordinary Deny does not always win across multiple Command Sets
Imagine two sets are evaluated:
- Set A returns an ordinary Deny for a command.
- Set B returns Permit for the same request.
It is easy to assume that A must win. That is not how the documented multi-set evaluation works.
In brief:
- A matching Deny Always takes precedence.
- Without one, a Permit from any evaluated set allows the command.
- Otherwise, it is denied, subject to the unmatched-command permission setting.
Within a set, matching and rule order also matter. Inspect the actual request and the complete combination of sets.
The answer is not to replace every Deny with Deny Always. First determine what matched, what permitted the request, and whether permission for unmatched commands affected the result.
GUI access may use a different authorization mechanism
Restricting commands in the CLI does not prove that the same account is read-only in the GUI.
Cisco's Catalyst 9800 configuration article, based on C9800-CL 17.9.2 and ISE 3.2.0, documents these WebUI restrictions:
- Privilege levels 1–14 can access only the Monitor tab.
- Privilege level 15 provides full access.
- Using privilege level 15 with a restricted Command Set to enforce WebUI read-only access is unsupported; configuration changes may still be possible through the WebUI.
That is a very different situation from a typo in a Command Set.
Do not generalize the example to every WLC, release, or access method. Check support at the level of:
Product × OS version × access method (CLI, GUI, API, and so on).
My troubleshooting checklist
| What you have established | What to check next |
|---|---|
| TACACS+ login succeeds | Authorization request for the target operation |
| No corresponding authorization request is visible | Device configuration, supported method, and log filters |
| An unexpected policy rule matched | Policy conditions and evaluation order |
| The expected policy rule matched | Selected Profile / Command Sets |
| The expected Command Sets were selected, but the operation was allowed | Command, Arguments, multiple-set evaluation, and unmatched-command handling |
| The CLI is restricted, but the GUI allows changes | GUI authorization mechanism and product documentation |
| ISE shows Deny, but the operation appears to have succeeded | Same operation and session? Was a change actually applied? |
This turns “Command Sets don't work!” into something closer to:
The authorization request reaches ISE and matches the expected rule, but the result of evaluating multiple Command Sets differs from what we intended.
That is easier to investigate—and easier for TAC to respond to.
The same principle applies to read-only testing
If the goal is a read-only account, successful login is not the end of the test.
Check both sides:
| Operations that should work | Operations that should be denied |
|---|---|
| Required show commands | Configuration changes |
| Troubleshooting checks | Reloads |
| Required log access | Saving configuration or changing users |
Choose the actual test cases from your requirements and the product's supported controls. This table is illustrative, not a universal permissions list.
For tests involving configuration changes, saving, or reloading, assess the impact and recovery procedure in case the operation is unexpectedly allowed. Use a lab or another authorized test environment. Do not try such operations on production equipment on the assumption that “they should be denied.”
If people use both the CLI and GUI, test each access method.
The next topic in this series is why “the read-only user can log in” is not enough to finish an access-control test.
Follow the operation, not just the configuration screen
The lesson I took from working with Command Sets was simple:
“I created the configuration” and “that configuration controls this operation” are different claims.
Before changing Permit/Deny rules, work through these questions:
- What operation was unexpectedly allowed?
- Did its authorization request reach ISE?
- Which policy rule matched?
- Which Profile / Command Sets were selected?
- What command and arguments did the device send?
- How were multiple Command Sets evaluated?
- Does that access method use the mechanism you are investigating?
Looking only at the Command Set configuration screen cannot answer all of them.
That is this week's field memo.
Related: snmpwalk Works. Is Your Monitoring Actually Ready?
Original Japanese article: ISEでCommand Setsを作ったのに効かない？
This is an English adaptation of my Japanese article, prepared with AI translation assistance. Examples are generalized and contain no customer configurations or logs.
Official references
- Cisco ISE 3.5 — Device Administration: Command Sets, matching, evaluation, and TACACS Profiles.
- RFC 8907 — TACACS+: authentication, authorization, and accounting.
- Cisco — Configure RADIUS & TACACS+ for GUI & CLI Authentication on Catalyst 9800 WLCs: the version-specific WebUI example.
Support and behavior depend on the product, OS version, and access method. Check the official documentation for the version you actually use.
Top comments (0)