Access Control List (ACL) Scenarios

deny ip any 10.1.1.0 0.0.0.255

Why it fails: This denies only IP traffic to the subnet, so non-IP protocols still pass, and it omits the trailing permit needed for everything else. It is tempting because it names the target subnet correctly. The requirement needs deny ip any 10.1.1.0 0.0.0.255 followed by permit ip any any as the last line.

permit tcp any any

Why it fails: A trailing permit tcp any any only allows TCP, dropping UDP, ICMP and other protocols that the requirement says must still reach non-denied destinations. It is tempting because it mirrors a typical implicit-permit replacement. The final line must be permit ip any any, placed after the deny for 10.1.1.0/24.

deny ip any any

Why it fails: Denying all traffic as the final line blocks every destination, not just the server subnet, contradicting the requirement to permit everything else. It is tempting because it guarantees the subnet is denied. The last line must instead be permit ip any any, with the subnet deny placed before it.

SGACL tag format

Why it fails: SGACL tag format is the syntax used inside security group ACL definitions, not the mandatory format for dACL access control list entries, which require the security group tag plus permit or deny statement. It is tempting because SGACLs and dACLs both use SGT values, and would be correct when writing the SGACL body itself.

JSON format

Why it fails: Windows security descriptors store ACEs in binary form, not JSON; the dACL is edited through PowerShell objects or the GUI, which serialise to SDDL. JSON suits REST API payloads and configuration files, so it would be the right choice when exchanging structured data with a web service, not when defining access control entries.

XML format

Why it fails: XML is not the format Cisco ISE accepts for a dACL; entries are returned as a string of ACEs (for example, "permit ip any any"), which the NAD parses. XML suits structured policy exchange between systems, such as pxGrid context sharing, not the downloadable ACL attribute itself.

The ISE Policy Set has 'Deny' as the default

Why it fails: A Policy Set default of Deny applies only when no rule matches the request; a matching rule with a Command Set permitting the command would still authorise it. It is tempting because default-deny behaviour does block unmatched sessions, but the stem states the Command Set already contains Permit, so the failure lies in matching or command-set assignment.

The user is in the wrong AD group

Why it fails: Group membership affects which authorisation policy or command set the admin matches, but the stem already establishes that a Command Set with Permit exists and is presumably assigned. It is tempting because wrong group placement commonly causes authorisation failures, yet the question asks why a permitted command still fails, which points to command-set configuration.

The TACACS+ shared secret is incorrect

Why it fails: An incorrect TACACS+ shared secret breaks authentication between the network device and ISE, so the admin session fails before any authorisation policy is evaluated. It is tempting because secret mismatches do cause login failures, but here the admin authenticates successfully and only one command is refused, which points to command-set or policy-set evaluation instead.

The Command Set is not applied in the Policy Set

Why it fails: If the Command Set were not applied in the Policy Set, the user would receive no authorisation at all rather than a Command Set permitting all commands. It is tempting because policy binding is a common configuration oversight, and verifying it would be correct when a user's assigned rules appear to have no effect whatsoever.

The device is not authorized for the command

Why it fails: Device authorisation governs whether the network device itself may authenticate to the server, not whether an individual user's command is permitted. It is tempting because authorisation failures do produce 'Access Denied', and checking device authorisation would be correct when the NAD cannot authenticate to the TACACS+ server at all.

The TACACS+ server is unreachable

Why it fails: An unreachable TACACS+ server would deny all commands, not selectively block 'reload' while permitting everything else in the Command Set. It is tempting because server reachability is a frequent cause of authorisation failures, and checking it would be correct when users are denied every command or authentication itself times out.

In the External Identity Source configuration for the 'NetOps' group, add the permitted commands as attributes.

Why it fails: External identity sources, such as Active Directory, store user attributes and group memberships, but they do not store command authorization permissions. Command sets are defined within ISE and referenced in authorization policies. Adding commands as attributes in an external identity source is not a supported method for TACACS+ command authorization.

In the TACACS+ Command Authorization settings under Device Administration, create a command set and assign it directly to the user's group.

Why it fails: While there is a TACACS+ Command Authorization configuration area, command sets are not assigned directly to user groups there. Instead, they are referenced in Authorization Policy rules. The assignment to groups occurs via policy conditions. Direct assignment to groups is not the ISE workflow, so this option is incorrect.

In the Policy Set's Allowed Protocols section, enable TACACS+ and specify the allowed command list.

Why it fails: The Allowed Protocols section determines which authentication protocols (like PAP, CHAP, MS-CHAP) are permitted for the policy set. It does not define command sets or command authorization. Command authorization is handled separately in the Authorization Policy with Command Sets. Therefore, this option is incorrect.

Deny: show *; Permit: show running-config

Why it fails: If the deny for 'show *' is placed first, it will match 'show running-config' and deny it before the permit is evaluated. Command Sets are processed in order, so the first matching entry is applied. Therefore, this order would deny all show commands, including the one that should be permitted. The permit must come before the deny.

Permit: show running-config; Permit: show *

Why it fails: This configuration permits both 'show running-config' and all other show commands. It does not deny anything, so users would be able to execute any show command. The requirement is to deny all other show commands, so a deny entry is necessary. This configuration fails to restrict commands.

Permit: show *; Deny: show running-config

Why it fails: This configuration permits all show commands and then denies 'show running-config'. Since the permit for 'show *' comes first, it will match 'show running-config' and allow it, making the subsequent deny ineffective. This would allow all show commands, which is the opposite of the requirement.