Aaa Radius Tacacs practice questions

The WLC is configured with the wrong authentication port; RADIUS uses port 1645, not 1812.

Why it fails: This is incorrect because RADIUS authentication uses UDP port 1812 as the IANA-assigned standard port; port 1645 is a legacy alternative from early RADIUS implementations that has been deprecated due to conflicts with the datametrics service. More importantly, the server logs in the scenario show that the WLC's Access-Request messages are being received, which proves the WLC is sending to the correct destination port (1812). If the WLC were mistakenly configured for 1645, the requests would never reach the RADIUS listener on 1812, and no Access-Reject entries would appear in the server logs.

The WLC's RADIUS server configuration has the wrong shared secret, causing the server to reject requests.

Why it fails: Incorrect because the server logs show 'Access-Reject', which indicates the server received the request and processed it; a shared secret mismatch would typically result in no response or a 'Access-Challenge' but not necessarily a reject. However, the server could still reject if the secret is wrong, but the WLC would still see a response, not 'server not responding'.

The WLC is not configured with a valid management interface IP address to reach the RADIUS server.

Why it fails: This is incorrect because the RADIUS server logs show that it is receiving Access-Request packets from the WLC, which proves the WLC's management interface has a valid IP address and can route to the server. An invalid management interface IP (or missing route) would prevent the WLC from sourcing or sending any RADIUS traffic, so the server would see nothing at all. The real issue is asymmetric routing or a source-address mismatch: the server replies from a different IP than the configured RADIUS server address, causing the WLC to drop those responses and log 'server not responding'.

The switch must have 'aaa authentication dot1x default group radius' configured globally.

Why it fails: This global configuration is already assumed to be in place in the scenario, as the switch is attempting 802.1X authentication and the failure occurs at the interface level. The command 'aaa authentication dot1x default group radius' only specifies the authentication method and server; it has no role in assigning a VLAN to a failed or unauthenticated host. The missing piece is the interface-specific guest VLAN definition, not a global authentication rule.

The 'authentication host-mode multi-host' command should be replaced with 'authentication host-mode multi-domain' to support guest VLAN.

Why it fails: Replacing 'multi-host' with 'multi-domain' would change how multiple devices are authenticated on the port, but it does not affect whether a guest VLAN can be used. 'Multi-domain' restricts the port to one voice and one data device, while 'multi-host' allows any number of devices after a single successful authentication. Both host modes support a guest VLAN; the actual problem is that no guest VLAN has been configured with the 'authentication guest-vlan' command.

The port must be configured as a trunk port to allow the guest VLAN.

Why it fails: The guest VLAN is a single, untagged VLAN that the switch dynamically assigns to an access port when authentication fails; it is not a trunk VLAN. Trunk ports are designed to carry multiple VLANs with tagging, which would introduce unnecessary complexity and security risk for a guest access environment. A standard access port with 'authentication guest-vlan' is sufficient, and the command works regardless of the port's trunk or access mode—but using trunk would not solve the missing VLAN definition.

30 seconds

Why it fails: 30 seconds is a commonly configured value for the quiet-period, but it is not the default. Network administrators sometimes lower the timer to 30 seconds to reduce the delay after a failed authentication, allowing clients to retry sooner. However, Cisco's default on IOS/IOS-XE switches is 60 seconds, making this an intentional tuning choice rather than a standard setting.

120 seconds

Why it fails: 120 seconds is a more restrictive quiet-period that is sometimes configured in high-security environments to further throttle authentication retries after failures. It is not the default; it is a deliberate override to slow down potential attackers. Choosing this value extends the lockout window, which can frustrate legitimate users but adds an extra layer of brute-force mitigation.

10 seconds

Why it fails: 10 seconds is the default for the tx-period (or 'timeout tx-period') in Cisco 802.1X, not the quiet-period. The tx-period controls how often the switch retransmits EAP-Request/Identity frames when no response is received, defaulting to 10 seconds. Confusing these two timers is a common mistake because both deal with authentication timing, but they serve fundamentally different purposes.

The switch is not configured for 802.1X on the interface.

Why it fails: This is incorrect because Cisco TrustSec does not strictly require 802.1X authentication on an interface. When the interface is configured with 'cts manual' and a manually assigned SGT is applied to untagged traffic, the switch can classify packets without any 802.1X session. The absence of 802.1X only means there is no dynamic authentication or SGT propagation via RADIUS, but manual SGT assignment can still be fully operational. Therefore, a missing 802.1X configuration does not explain why role-based policies are not enforced.

The 'cts manual' command is incorrect; 'cts dot1x' should be used instead.

Why it fails: This is wrong because 'cts manual' is a completely valid command for trusted interfaces where SGTs are manually assigned to untagged or non-802.1X traffic. It is not a typo or an invalid alternative to 'cts dot1x'—the two modes serve different purposes: 'cts dot1x' is used when the switch relies on 802.1X and RADIUS to dynamically receive SGTs, while 'cts manual' is used for static SGT assignment on trusted links. The problem is not the command syntax but that the SGT mappings themselves are missing on the switch, so the classification cannot occur regardless of which mode is configured.

The 'show cts role-based counters' command shows no drops, indicating the ACLs are not configured.

Why it fails: This is incorrect because 'show cts role-based counters' only displays the number of packets that were actually dropped by role-based access control lists. If enforcement is not active—for example, because the SGTs are missing or the RBACL is not applied to the relevant source/destination pair—the counters will remain at zero, even if an ACL is configured somewhere. The command does not show whether ACLs are configured or attached; it only shows the outcome of enforcement. Therefore, zero drops simply indicate that no packets were rejected, which is consistent with the switch lacking SGT mappings and never evaluating a policy.

The switchport is configured as 'switchport mode trunk', which does not support dACLs.

Why it fails: dACLs are fully supported on trunk-mode switchports; the switch applies a downloadable ACL as a per-port, per-host policy after 802.1X authentication, regardless of whether the interface is an access or trunk port. A trunk configuration does not preclude dACL enforcement, especially when a single authenticated host is mapped to the interface. Therefore, the guest's lack of restriction cannot be attributed to trunk port mode.

The guest is not being authenticated; the switch is using MAB instead.

Why it fails: If MAB were in use, the switch would still query RADIUS and would apply any dACL attributes included in the Access-Accept message, so MAB does not inherently skip dACLs. Moreover, the scenario indicates the guest completed 802.1X authentication, so MAB is not the mechanism in play. The failure to filter traffic stems from the RADIUS server not returning the dACL attributes, not from the authentication method.

The switch is not configured with 'ip access-group' to apply the dACL.

Why it fails: Downloadable ACLs are installed dynamically by the switch when the RADIUS Access-Accept includes the dACL attributes; no explicit 'ip access-group' command is required or used to bind a dACL to an 802.1X-authenticated port. Manual access-group configurations apply static ACLs and are not part of the dACL workflow, so their absence cannot explain the missing filter. The switch would automatically enforce the dACL if the RADIUS server actually delivered it.

Fabric edge node

Why it fails: The fabric edge node is the access switch that attaches endpoints to the SD-Access fabric; it enforces the policy by applying SGACLs based on the SGT carried in the VXLAN header. However, it does not assign the SGT—it receives the tag as an authentication result from ISE over RADIUS or, in some designs, via SXP. The edge's role is forwarding and enforcement, not identity classification; treating the edge as the SGT source misunderstands the trust boundary in the fabric.

Fabric control plane node

Why it fails: The fabric control plane node implements the LISP mapping system, maintaining the EID-to-RLOC database that lets the fabric perform location/identity separation. LISP operates at Layer 3 and is concerned with reachability and routing, not with user identity or security policy classification. SGT assignment is an authorization decision from ISE and is propagated separately from the EID-to-RLOC mappings, so the control plane node has no role in creating or assigning the tag.

Cisco DNA Center

Why it fails: Cisco DNA Center serves as the controller and management plane for SD-Access, automating device onboarding, fabric provisioning, and policy intent. Although DNA Center can display and push policy configuration to devices, it does not authenticate endpoints and cannot independently generate or assign an SGT; the actual assignment is performed by ISE in its role as the Policy Service Point. DNA Center's visibility into security policy is aggregated from ISE, not created by the controller itself.

Both RADIUS servers are currently unreachable.

Why it fails: The 'current UP' state in the output explicitly indicates that the RADIUS server is currently reachable and passing keepalives or health checks. A server that is unreachable would typically be marked as 'current DOWN' or have a dead counter incrementing, but both servers show a live status. Thus, this is incorrect because the current administrative and operational state is UP, not unreachable.

Server 192.168.1.10 is the backup server.

Why it fails: In RADIUS server groups, a lower priority value (like 1) designates the primary server; the server with priority 1 is tried first and is therefore the primary, not backup. The server with a higher priority number, such as 192.168.1.20 with priority 2, would be the backup. Since 192.168.1.10 has priority 1, it is the primary server, so calling it the backup is incorrect.

TACACS+ is also configured on these servers.

Why it fails: The command output is specifically from a RADIUS server group view, showing RADIUS-specific parameters like retransmit counts, dead-total, and current status. There is no mention of TACACS+ servers or shared secrets, nor is there a separate TACACS+ configuration block. RADIUS and TACACS+ are separate AAA protocols with distinct server configurations, so asserting TACACS+ is configured on the same servers without evidence is unsupported.

The RADIUS server is not sending the correct VLAN ID in the Access-Accept.

Why it fails: This is incorrect because the symptom is that client devices receive an IP address in VLAN 100 and can associate, but cannot reach resources beyond the access switch. If the RADIUS server were sending an incorrect VLAN ID, the clients would either be placed in a different VLAN than intended (e.g., a guest VLAN) or authentication would fail outright. The problem is not on the RADIUS side; the Access-Accept is valid and correctly specifies VLAN 100 for the wireless clients.

The WLC is not configured for 802.1X on the uplink to the switch.

Why it fails: This is incorrect because 802.1X is a port-based access control method designed for point-to-point links and is not used on the uplink between a WLC and a switch. The WLC-to-switch link is normally configured as a trunk or an access port carrying multiple or a single VLAN, and it should not run 802.1X. Even if 802.1X were misconfigured on the uplink, it would not affect the drop of tagged VLAN 100 frames, because the issue is with VLAN pruning, not with port authentication.

The users' devices are not configured for MAB.

Why it fails: This is incorrect because MAB (MAC Authentication Bypass) is a fallback mechanism for devices that do not support 802.1X supplicants, such as printers or legacy devices. Wireless clients using 802.1X authenticate via the WLC, which acts as the authenticator (or passes EAP frames to the RADIUS server), and they do not require MAB. The problem described is about VLAN tagging on the trunk, not about the inability of the clients to perform 802.1X; MAB is irrelevant and would be a redundant fallback on the WLC, not a client-side setting.

All login attempts use TACACS+ authentication; exec accounting is local.

Why it fails: This option reverses both authentication and accounting elements from the actual configuration. The `aaa authentication login default local` command explicitly selects the local username/password database as the method, not TACACS+; no TACACS+ group is referenced in the authentication method list. Similarly, the accounting command `aaa accounting exec default start-stop group tacacs+` sends EXEC accounting data to the TACACS+ server, not to local accounting logs. Therefore, this statement is incorrect on both counts.

Console login uses TACACS+; VTY login uses local; accounting is sent to TACACS+.

Why it fails: It presupposes separate authentication method lists for console and VTY. In the given configuration, only a single default method list is defined under `aaa authentication login default local`, and both console and VTY automatically reference this same default list. Therefore, all login transports, including console and VTY, authenticate against the local username database. The accounting part is accurate—`aaa accounting exec default start-stop group tacacs+` sends EXEC start and stop records to TACACS+—but the authentication split is unsupported by the config.

Authentication and authorization are both performed by TACACS+; accounting is local.

Why it fails: This option is the inverse of the correct behavior: authentication and authorization are both local, while accounting is remote. The absence of `group tacacs+` in the `aaa authentication login default` and `aaa authorization exec default` lines confirms that the router consults its local username database for both functions. In contrast, `aaa accounting exec default start-stop group tacacs+` designates TACACS+ as the sole accounting destination. Because the three AAA sub-services are configured independently, using TACACS+ only for accounting is perfectly valid and does not imply it is used for the other two.

The switch dynamically assigns the SGT based on the MAC address.

Why it fails: The switch is only an enforcement point in TrustSec; it does not make policy decisions and cannot derive a security classification from a MAC address alone. MAC addresses are easily spoofed and carry no user or device role information, so a dynamic MAC-based assignment would create a static, insecure mapping. Instead, the switch receives the SGT from ISE in the RADIUS Access-Accept, and its local role is limited to applying that tag and the associated SGACL rules.

The endpoint device sends its SGT in the EAPOL-Start message.

Why it fails: EAPOL-Start is a low-level EAP message sent by the endpoint to initiate 802.1X authentication; it contains only a basic EAP header and no application payload, so it cannot carry an SGT. Moreover, at the time EAPOL-Start is sent, the endpoint has not yet provided any credentials, so no identity exists to derive an SGT from. The SGT is a post-authentication classification assigned by ISE and delivered to the switch in the RADIUS Access-Accept, never in an EAPOL message.

The SGT is derived from the VLAN ID assigned to the port.

Why it fails: VLAN assignment is a Layer 2 concept that groups ports into broadcast domains, while the SGT is a 16-bit security classification that crosses Layer 2 boundaries and maps to security group ACLs. Although ISE can return both a VLAN and an SGT in the same Access-Accept, they are independent attributes: the VLAN controls network reachability, while the SGT controls security policy. The switch does not derive one from the other; an endpoint in the same VLAN can have different SGTs based on its identity.

The port-channel is a Layer 2 interface because it has an IP address.

Why it fails: The statement is incorrect because an IP address on a port-channel interface does not make it Layer 2; rather, it designates the interface as a Layer 3 (routed) port. In Cisco IOS, assigning an IP address to a port-channel creates a routed interface, whereas a Layer 2 port-channel requires the 'switchport' command and operates as a VLAN trunk or access port, without an IP address. Therefore, the presence of an IP address is evidence of Layer 3 operation, not Layer 2.

The interface is experiencing input errors due to CRC errors.

Why it fails: The claim that the interface is experiencing input errors due to CRC errors is false because the provided output shows '0 input errors' and '0 CRC' counters. CRC errors, such as those caused by physical layer noise or faulty cabling, would appear as a non-zero value in the input error and CRC error fields. Since both counters are zero, there is no evidence of any input error or CRC-related problem on this port-channel.

The port-channel is operating at half-duplex.

Why it fails: The statement that the port-channel is operating at half-duplex is directly contradicted by the interface output, which explicitly shows 'Full-duplex'. EtherChannel member links must operate in full-duplex mode to avoid collisions and ensure proper aggregation, and the output confirms that this requirement is satisfied. A half-duplex operation would be a misconfiguration and would appear as 'Half-duplex' in the show output, which is not the case here.

Accounting records are sent to TACACS+ at both session start and end.

Why it fails: If the administrator had used the `start-stop` keyword, the router would send an accounting start record when the EXEC session begins and a stop record when it ends. However, the configuration shown uses `stop-only`, which explicitly suppresses the start record and sends only the stop record. Therefore, this option mischaracterizes the configured behavior.

Accounting records are sent to TACACS+ only at session start.

Why it fails: The `stop-only` keyword means no start record is sent at the beginning of the EXEC session; only a stop record is transmitted at termination. Because the router never sends a start record, claiming that records are sent only at session start is the exact opposite of the configured behavior. This option would only describe a hypothetical (and nonstandard) 'start-only' configuration, not the command in question.

Accounting is disabled because the command uses 'stop-only' incorrectly.

Why it fails: The `stop-only` syntax is a valid and recognized keyword for the `aaa accounting exec` command in Cisco IOS. It does not disable accounting; rather, it defines that only the stop accounting record is produced. The command is correctly formed and fully functional, so accounting is enabled — just with a limited set of records.

The router's 'aaa authorization commands 15 default group tacacs+' command is missing the 'local' keyword, so if TACACS+ denies, there is no fallback.

Why it fails: Incorrect because the engineer wants TACACS+ to authorize commands, and the issue is that TACACS+ is responding with a deny, not that the router is failing to fall back. Adding 'local' would not help if TACACS+ explicitly denies.

The router's privilege level 15 is not correctly assigned to the user.

Why it fails: This is not the cause because the user is already operating at privilege level 15, as evidenced by the 'aaa authorization commands 15' statement in the router's configuration. The router's privilege level determines which commands require authorization and what local permissions exist, but in this scenario, the final decision lies with the TACACS+ server, which is explicitly denying the commands. A correct privilege level assignment does not guarantee that TACACS+ will authorize every command; the server's rules are separate and must allow the command regardless of the user's privilege level.

The TACACS+ server is not reachable due to a firewall change, causing the router to deny all commands.

Why it fails: The issue is not with reachability because the TACACS+ server logs confirm that it is receiving authorization requests and sending responses back to the router. If a firewall were blocking traffic, the router would not receive responses and would either time out or fall back to a default authorization method, which is not what the logs show. The fact that the server is responding indicates the network path is functional, so the problem must be in the server's authorization policy, not in connectivity.

The user jdoe failed authorization.

Why it fails: The debug output explicitly displays a PASS response from the TACACS+ server for the authorization request of user jdoe. A PASS message indicates that the server approved the user's authorization, meaning the user was granted the requested access. Therefore, stating that the user failed authorization directly contradicts the captured debug evidence.

Authorization was performed using RADIUS.

Why it fails: The debug output clearly identifies the protocol as TACACS+, not RADIUS. TACACS+ uses TCP and encrypts the entire packet body, while RADIUS uses UDP and encrypts only the password. The presence of TACACS+-specific attributes and the selected method in the debugging session confirm that RADIUS was not used for this authorization.

The user was authenticated but not authorized.

Why it fails: The debug output shows that the TACACS+ server returned a PASS response to the authorization request, proving that authorization was both performed and successful. Saying the user was authenticated but not authorized would imply that the authorization phase either failed or was skipped, which is not the case here. The PASS result clearly indicates the user was fully authorized after authentication.