RADIUS authentication problems in Cisco ISE are rarely solved by staring at a single \u201cAccess-Reject\u201d message. A complete transaction crosses the endpoint, supplicant or browser, access switch or wireless controller, network path, ISE Policy Service Node, identity store, authentication policy, authorization policy, and sometimes a Change of Authorization after the first decision. Effective troubleshooting follows that chain and proves where the expected state diverges from the actual state.<\/p>\n
Within Troubleshooting RADIUS Authentication in Cisco ISE, the current 300-715 SISE<\/a> v1.2 blueprint includes policy enforcement, 802.1X, MAB, guest services, and network access device administration. Cisco ISE 3.4 exposes RADIUS Live Logs and detailed authentication reports specifically to make each transaction explainable. The goal is to interpret those records rather than treating ISE as a black box that either accepts or rejects a user.<\/p>\n Record the user or endpoint identity, MAC address, access device, interface or SSID, approximate time, authentication method, and expected result. \u201cWi-Fi does not work\u201d is too broad. \u201cUser alice@example.com on Corp-WLAN at 10:14 receives EAP-TLS failure before authorization\u201d immediately narrows the search. For MAB, the endpoint MAC and switch port may be more important than a username.<\/p>\n Also determine whether the failure is authentication, authorization, or post-authentication connectivity. A user can authenticate successfully and still receive a restrictive authorization profile. A session can receive the correct VLAN and still fail because DHCP or routing is broken. Separating identity decisions from network forwarding prevents an ISE administrator from editing policy to fix a downstream problem that RADIUS already handled correctly.<\/p>\n ISE RADIUS Live Logs show recent requests, pass\/fail status, identity, network device, policy set, authentication method, authorization result, and a details view for the selected transaction. Treat the log entry as an index into the decision path. First confirm that the request arrived at the expected Policy Service Node. If there is no log entry, the problem is upstream of ISE or the request is going to a different node.<\/p>\n When the record exists, read the detailed steps in sequence. They can reveal a failed EAP negotiation, an identity-store lookup issue, an unmatched policy condition, a certificate validation problem, or an explicit rejection. The Cisco ISE access-control<\/a> workflow is rule-driven, so the details should explain not only the result but the rule and identity source that produced it.<\/p>\n ISE must recognize the RADIUS client. Confirm the source address used by the switch, controller, firewall, or VPN headend matches the configured network device entry. Check the shared secret on both sides and confirm that intermediate NAT has not changed the apparent source unexpectedly. A shared-secret mismatch commonly produces symptoms that resemble an authentication failure but never reach normal policy evaluation.<\/p>\n Review the network device profile and RADIUS settings when using nonstandard platforms. The profile influences how ISE interprets attributes, flow types, and MAB behavior. If one device works and another identical policy does not, compare their RADIUS source interfaces, device definitions, dictionaries, and firmware behavior before cloning authorization rules. Infrastructure differences often explain \u201csame user, different result\u201d cases.<\/p>\n For wired or wireless 802.1X, confirm the endpoint is actually attempting the expected EAP method. Supplicant configuration, certificate selection, username format, server-certificate validation, and EAP timers all matter before authorization policy can run. If 802.1X fails and the switch falls back to MAB, the ISE log may show a completely different identity and rule than the operator expects.<\/p>\n MAB is a host lookup using the endpoint MAC address and is weaker than cryptographic user or machine authentication. It is useful for printers, phones, sensors, and devices without a supplicant, but it should not silently become the universal rescue path for broken 802.1X. Review endpoint profiling and exception policy so a failed corporate laptop does not receive the same treatment as a legitimately MAB-only device.<\/p>\n Authentication policy determines which identity source or sequence ISE will use. The same person may appear as a UPN, domain-qualified name, certificate subject, or local identity depending on the method. Read the username and selected identity store from the authentication details. Do not assume that because Active Directory is joined, every request is querying the expected domain or identity source.<\/p>\n For certificate-based authentication, inspect the certificate chain, validity, revocation status, Extended Key Usage, subject or SAN mapping, and ISE certificate-authentication profile. For password-based EAP, distinguish wrong credentials from domain reachability or machine-account problems. The purpose of the identity-store trace is to answer a concrete question: did ISE search the expected source for the identity form that the endpoint actually sent?<\/p>\n ISE evaluates policy sets and then the authentication and authorization rules within the selected set. An overly broad condition near the top can capture requests that were intended for a more specific set. Likewise, a carefully written authorization rule never runs if the request entered the wrong policy set. When troubleshooting, record the matched policy set and compare the actual RADIUS attributes with the condition logic.<\/p>\n A useful practice is to build conditions around stable attributes such as network device groups, SSIDs, wired flow type, EAP method, identity group, or endpoint profile, and then document why each rule exists. This reduces ambiguous matches. The broader idea of dynamic access control<\/a> is that context selects policy; in ISE, the quality of that context directly determines the authorization result.<\/p>\n An Access-Accept only proves that ISE accepted the authentication and returned a result. Verify which authorization profile was selected and which attributes were sent: VLAN, downloadable ACL, security group, redirect, session timeout, or other vendor-specific values. Then check the access device session to confirm it applied them. Unsupported or malformed attributes can make the ISE side look correct while the network side behaves differently.<\/p>\n If a VLAN change is involved, verify that the VLAN exists and is allowed on the path, and then confirm the endpoint receives the expected address. A post-authentication address failure belongs in DHCP and switching troubleshooting, not in credential policy. The DHCP process<\/a> is a common next dependency after successful network authorization, so prove the boundary between RADIUS success and client connectivity.<\/p>\n When ISE and the network device disagree about what was sent, capture packets on the relevant path. A RADIUS capture can show request source address, packet timing, retransmissions, EAP messages carried inside RADIUS, Access-Challenge sequences, and the returned attributes. Compare the packet evidence with the timestamps in Live Logs and with the access device debug or session output.<\/p>\nStart with a precise definition of the failed transaction<\/h3>\n
Use RADIUS Live Logs as the transaction index<\/h3>\n
Verify the network access device definition before changing policy<\/h3>\n
Distinguish 802.1X failures from MAB fallbacks<\/h3>\n
Trace identity-store selection and the username actually presented<\/h3>\n
Read policy-set conditions as ordered logic<\/h3>\n
Confirm authorization attributes reach and are accepted by the access device<\/h3>\n
Use packet captures when logs cannot prove the exchange<\/h3>\n