Cisco 350-701: Troubleshooting TACACS+ and RADIUS AAA

AAA separates three questions that are often blurred together during troubleshooting:

Authentication: Who are you?
Authorization: What are you allowed to do?
Accounting: What did you do?

Cisco platforms can use TACACS+ and RADIUS to answer those questions, but the protocols are commonly used for different access problems. The current 350-701 SCOR v2.0 blueprint explicitly requires candidates to troubleshoot AAA for device and network access using TACACS+ and RADIUS.

Start by identifying the access type

The first troubleshooting question should be: What is being authenticated?

If an administrator is logging into a router, switch, firewall, or other infrastructure device, TACACS+ is commonly used for device administration.

If an endpoint is joining the network through 802.1X, MAB, wireless access, or another network-access method, RADIUS is commonly used.

That distinction immediately narrows the expected policy, logs, attributes, and failure points.

RADIUS is the common policy transport for endpoint network access, but troubleshooting still begins with what the AAA server is being asked to authenticate and authorize.

The transport details help confirm that the right transaction is even reaching the policy server. TACACS+ device administration commonly uses TCP port 49, while RADIUS commonly uses UDP 1812 for authentication and authorization and UDP 1813 for accounting. Those defaults can be changed or proxied, so the real test is the configured path on the network device and ISE rather than a memorized port number.

Source IP is equally important. ISE identifies the network access device from the address that sends the AAA request. A router or switch can successfully ping an ISE node from one interface while sourcing TACACS+ or RADIUS from another. If that source is not defined with the expected shared secret and device groups, the request can fail before the intended policy set is evaluated.

Authentication proves the identity

Authentication checks the supplied identity against an identity source.

For a network administrator, that can mean validating credentials before allowing a CLI session.

For an endpoint, that may mean 802.1X credentials, certificates, or another configured method.

A failure at this stage means the system has not accepted the identity.

Common causes include:

wrong username or password
certificate trust or validity problems
wrong identity store
network device using the wrong AAA server
mismatched shared secret
unsupported authentication method
unreachable policy service node

Do not jump to authorization troubleshooting until authentication actually succeeds.

Authorization decides the result after authentication

A user can authenticate successfully and still be denied the requested privilege.

That is an authorization problem.

Cisco ISE can return different results depending on access type.

For TACACS+ device administration, authorization can include shell profiles and command sets that control what an administrator may execute.

For RADIUS network access, authorization can include VLAN assignment, security group information, ACL behavior, and downloadable ACLs.

That means “login worked” proves only the authentication step. It does not prove that the correct authorization policy matched.

Authorization should be read as a policy result, not as a second password check. In ISE device administration, the authentication rule establishes the identity source and method, then the authorization rule can return a shell profile, one or more command sets, or both. A user who reaches the CLI but cannot enter configuration mode may therefore be authenticating perfectly and receiving exactly the wrong authorization result.

Command authorization can be granular enough to permit operational commands while denying configuration commands. That is useful for least-privilege administration, but it creates more evidence points during troubleshooting: the policy-set match, the authorization rule, the shell profile, and the command-set decision can all be correct or incorrect independently.

TACACS+ is designed for granular device administration

Cisco ISE uses TACACS+ device administration to control and audit access to network devices.

A device administrator logs into infrastructure equipment, and ISE can apply policy to the session.

Command sets allow granular control over which CLI commands are authorized.

Shell profiles can define privilege and session behavior.

Accounting records can then log administrative actions.

This is a stronger fit for infrastructure administration than simply granting every authenticated administrator the same privilege level.

It also gives troubleshooting a clear policy path: identity → device administration policy set → authorization rule → shell profile / command set.

RADIUS is central to network access control

RADIUS is typically associated with endpoint network access.

A switch, wireless controller, firewall, or other network-access device sends an authentication request to ISE. If policy allows the session, ISE can return an Access-Accept with authorization attributes.

Those attributes can influence how the endpoint is placed and what it is allowed to reach.

The network device remains the enforcement point.

ISE makes the policy decision and returns the result.

This is the same general model behind dynamic network-access controls: centralized policy, distributed enforcement.

For RADIUS network access, the policy server and the enforcement device split the work. ISE returns authorization attributes; the switch, wireless controller, or other network access device applies them. If ISE shows the expected Access-Accept but the endpoint lands in the wrong VLAN or cannot reach the intended application, the investigation should move to the attributes received and the enforcement state on the network device.

Dynamic authorization introduces another useful boundary. A Change of Authorization can cause a live session to be reauthenticated, terminated, or given a different authorization result after posture or identity context changes. If policy has been corrected but an existing session still behaves according to an old result, check whether a reauthentication or CoA occurred rather than assuming the new policy was ignored.

Downloadable ACLs turn authorization into packet filtering

Cisco ISE can return downloadable ACLs, or dACLs, as part of a RADIUS authorization result.

A dACL contains filtering rules that are downloaded to the network enforcement device and applied to the session.

This gives the policy server more granular control than simply assigning a VLAN.

For example, two users can authenticate on the same access network but receive different traffic permissions.

The existing explanation of an access control list is useful for understanding permit/deny filtering. A dACL changes the delivery model: the policy is centrally defined in ISE and dynamically applied to the authenticated session.

Cisco ISE 3.4 documentation notes that if a required dACL does not exist, authorization can fail and ISE can return an Access-Reject.

A dACL has two dependencies: the authorization result must reference the intended ACL, and the network device must be able to obtain and install it. A policy result that names a nonexistent or unusable dACL is not equivalent to a locally configured ACL that simply contains the wrong permit statement.

When the session is accepted but traffic is wrong, confirm the exact downloaded ACL and the direction in which the platform applies it. Read the generated filter from top to bottom just as you would a normal ACL, but keep the delivery path in view: ISE defines the policy, RADIUS carries the authorization information, and the access device enforces the result.

Accounting is evidence, not access

Accounting records what happened after authentication and authorization.

For device administration, TACACS+ accounting can record sessions and command activity.

For network access, RADIUS accounting can record session starts, stops, updates, and other connection information depending on the deployment.

Accounting does not decide whether a user should be allowed in.

It helps answer questions after the access decision:

When did the session start?
Which device processed it?
Which policy result was applied?
What administrative command was executed?
When did the session end?

That makes accounting extremely useful during incident response and AAA troubleshooting.

Shared-secret errors can look like network or credential problems.

Both TACACS+ and RADIUS deployments rely on shared secrets between the network device and AAA server in common configurations.

If the secret does not match, the server and device cannot correctly validate the AAA exchange.

This can produce confusing symptoms because basic IP reachability may be fine.

The device can ping the server, yet AAA still fails.

When the AAA server appears reachable but requests are not being processed correctly, verify:

source IP used by the network device
network-device definition in ISE
protocol enabled for the device
shared-secret match
correct policy service node
firewall or ACL path for the AAA protocol

Accounting is especially valuable when the complaint is historical. Authentication logs explain whether the user was accepted; authorization logs explain the result; accounting records can show session start, stop, interim updates, and administrative command activity. Together they allow the engineer to reconstruct what the system believed at the time rather than relying on the user’s recollection after the session ended.

For administrator access, command accounting also creates an audit trail that can separate an authentication problem from a change-management problem. If a configuration changed successfully, the question may no longer be “why did AAA fail?” but “which authorized administrator executed the command, and under which policy result?”

Use the AAA logs before changing policy

Cisco ISE Live Logs and device-administration reports can show which policy set and rule were evaluated.

That is more reliable than guessing from the final user symptom.

If authentication succeeded but the wrong authorization profile was returned, inspect the conditions that caused that rule match.

If authorization failed because a dACL was missing, fixing the identity store will not solve it.

If the network device is unknown to ISE, rewriting authorization policy is premature.

The troubleshooting sequence should follow the AAA transaction.

Trace the AAA transaction end to end

Identify whether the use case is device administration or network access.
Verify IP reachability between the network device and ISE.
Confirm the correct source IP and network-device definition.
Verify the TACACS+ or RADIUS shared secret.
Confirm the authentication request reaches the intended ISE node.
Check whether authentication succeeded.
Inspect the authorization policy result.
Verify TACACS+ command sets/shell profiles or RADIUS authorization attributes.
For dACLs, verify the ACL exists and is downloadable.
Review accounting and session logs to confirm the final result.

The key is to avoid treating AAA as one binary pass/fail event.

Treat the AAA exchange as a sequence of evidence. First prove that the network device reached the intended ISE service with the expected identity and shared secret. Then confirm authentication, inspect the returned authorization result, verify enforcement on the device, and use accounting to reconstruct what happened. That sequence prevents a command-set problem, a dACL problem, and a credential problem from being collapsed into the same vague symptom.