> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # 802.1X Authentication Failing: Where to Start Troubleshooting - URL: https://www.pinglabz.com/802-1x-authentication-failing-troubleshooting/ - Published: 2026-03-24T03:04:44.000Z - Updated: 2026-07-04T23:02:22.000Z - Description: 802.1X auth fails across four layers: endpoint, switch port, RADIUS, ISE policy. Jumping straight to ISE logs wastes time. Here is the structured way to isolate the layer. - Author: Jaime - Tags: 802.1X, #Import 2026-08-01 19:54 ## Starting Point: Understand Where the Failure Is 802.1X authentication involves at least four distinct systems: the endpoint supplicant, the switch port (authenticator), the RADIUS server (ISE), and ISE's internal policy engine. A failure at any layer produces a different symptom signature. The worst approach is to jump straight to ISE logs or start modifying port configurations without first isolating which layer is failing. (This article is part of the PingLabz 802.1X series - the [full 802.1X guide](https://www.pinglabz.com/802-1x/) maps the whole cluster in reading order.) The structured approach: 1. Confirm the physical layer and port state 2. Confirm dot1x is enabled and operating on the port 3. Confirm RADIUS connectivity between the switch and ISE 4. Examine ISE authentication logs for the specific failure reason 5. Examine EAP exchange details if the failure is in the authentication phase 6. Check ISE policy - authorization rule evaluation This order matters. There is no value in examining ISE logs if the switch is not reaching ISE at all. There is no value in checking ISE policy if the EAP exchange is failing before ISE even receives a complete authentication request. ## Layer 1: Physical and Port State Before touching authentication configuration, confirm the basics. ``` SW9300# show interface GigabitEthernet1/0/5 status ``` Sample output: ``` Port Name Status Vlan Duplex Speed Type Gi1/0/5 connected 1 a-full a-100 10/100/1000BaseTX ``` If status shows `notconnect` or `err-disabled`, authentication has not started. Fix the physical layer or clear the err-disabled state first. ``` SW9300# show interface GigabitEthernet1/0/5 ``` Check for input errors, CRC errors, or interface resets - these indicate cabling or NIC issues that can cause intermittent authentication failures. If the port is in `err-disabled`: ``` SW9300# show interface GigabitEthernet1/0/5 | include err-disabled GigabitEthernet1/0/5 is down, line protocol is down (err-disabled) ``` Identify the cause: ``` SW9300# show errdisable recovery ``` Common 802.1X-related err-disable causes: `security-violation` (port security conflict), `dot1x-timeout` (not typically err-disable but worth checking), `bpduguard`. Fix the underlying cause before re-enabling: ``` SW9300# interface GigabitEthernet1/0/5 SW9300(config-if)# shutdown SW9300(config-if)# no shutdown ``` ## Layer 2: Confirm dot1x Port State ``` SW9300# show dot1x interface GigabitEthernet1/0/5 details ``` Sample output for a port where dot1x is enabled but authentication is failing: ``` Dot1x Info for GigabitEthernet1/0/5 ----------------------------------- PAE = AUTHENTICATOR QuietPeriod = 60 ServerTimeout = 30 SuppTimeout = 30 ReAuthMax = 2 MaxReq = 2 TxPeriod = 30 Dot1x Authenticator Client List -------------------------------- EAP Method = PEAP Supplicant = a4b1.c2d3.e4f5 Auth SM State = AUTHENTICATING Auth BEND SM State = RESPONSE Time = 00:00:28 ``` `Auth SM State = AUTHENTICATING` and `Auth BEND SM State = RESPONSE` after 28 seconds means the switch sent an EAP request to the supplicant and is waiting for a response that has not arrived. This points to a supplicant-side problem - the Windows Wired AutoConfig service is not running, the supplicant is not configured, or the endpoint's NIC is not passing EAPOL frames. Compare this to a RADIUS-side failure: ``` Auth SM State = HELD Auth BEND SM State = IDLE ``` `HELD` means the last authentication attempt failed and the switch is in a quiet period before trying again. This is the signature of authentication completing at the EAP level but being rejected by RADIUS - wrong credentials, invalid certificate, policy mismatch. ``` SW9300# show authentication sessions interface GigabitEthernet1/0/5 ``` Sample output: ``` Interface: GigabitEthernet1/0/5 MAC Address: a4b1.c2d3.e4f5 IP Address: Unknown Username: Unknown Status: Unauthorized Domain: UNKNOWN Security Policy: Should Secure Security Status: Unsecured ``` `Status: Unauthorized` with `Username: Unknown` indicates the switch never received an EAP Identity from the supplicant. The EAPOL exchange has not started. Check the supplicant configuration. In a Windows 10/11 environment, verify: - Wired AutoConfig service (dot3svc) is running: `sc query dot3svc` - The correct network profile is applied - The NIC adapter settings show the correct 802.1X authentication method `Status: Unauthorized` with a username present means the switch received the identity, completed the EAP exchange with ISE, but received an Access-Reject. This is an ISE policy or credential issue. ## Layer 3: Confirm RADIUS Reachability ``` SW9300# show aaa servers ``` Sample output: ``` RADIUS: id 1, priority 1, host 10.0.0.10, auth-port 1812, acct-port 1813 State: current UP, duration 3d02h, previous duration 0s Dead: total time 0s, count 0 Authentication: #sent 1432, #received 1280 Retransmission: #sent 152, #late responses 0 ``` `#sent 1432, #received 1280` with `Retransmission: #sent 152` indicates the switch is reaching ISE but 10% of packets are being retransmitted - a sign of latency or ISE performance issues. If retransmissions are consistently high, check network path between switch and ISE, and check ISE CPU/memory utilization. If state shows `DEAD` or `current DOWN`: ``` State: current DEAD, duration 00:02:15, previous duration 3d02h Dead: total time 135s, count 1 ``` This is a complete loss of RADIUS connectivity. See **Article 22 - RADIUS Server Unreachable in 802.1X: Causes and Fixes** for the full diagnostic procedure. Test connectivity directly: ``` SW9300# test aaa group ISE-SERVERS test-user test-password new-code ``` This sends a test Access-Request to ISE. A successful response: ``` Attempting authentication test to server-group ISE-SERVERS using radius User was successfully authenticated. ``` A failure: ``` User authentication request was rejected by server. ``` Rejection from ISE means RADIUS connectivity is working but ISE is rejecting the test credential - expected if `test-user` does not exist in ISE. What matters here is that ISE responded at all. If the command times out with no response, RADIUS is unreachable - check firewall rules, routing, and the `ip radius source-interface` configuration. ## Layer 4: ISE Authentication Logs **Navigation: Operations > RADIUS > Live Logs** Filter by: - **MAC Address** (Calling-Station-ID) - most reliable filter - **Username** \- if you have it - **NAS IP Address** \- narrows to failures from a specific switch Each failed authentication entry shows a **Failure Reason** field. This is the most direct path to the root cause. Common failure reasons: 11001 - RADIUS packet already in the process Duplicate packet; retransmission issue 11036 - MSCHAP authentication failed Wrong password or NTHash mismatch 12153 - EAP-FAST failed SSL/TLS handshake Certificate trust issue 12321 - PEAP failed SSL/TLS handshake ISE certificate not trusted by client 15039 - Rejected per authorization profile Identity matched but authorization rule denied 22040 - Wrong password or invalid shared secret User credential failure 24423 - User rejected by AD AD account locked, expired, or not in authorized group Click on any failed log entry to open the **Authentication Detail Report**. This shows the complete authentication sequence, which policy set was evaluated, which rules matched, and what ISE returned. **Navigation: Operations > Reports > Endpoints and Users > Authentication Summary** For repeated failures from the same endpoint, run this report filtered by MAC address or username over a 24-hour window. Patterns in failure reasons across multiple attempts reveal consistent misconfigurations rather than one-off issues. ## Layer 5: EAP Exchange Analysis When ISE shows the authentication is reaching the EAP exchange phase but failing, use debug on the switch to see exactly where the EAP conversation breaks. ``` SW9300# debug dot1x events SW9300# debug dot1x packets SW9300# debug radius authentication ``` Trigger an authentication attempt (disconnect and reconnect the endpoint, or run `authentication restart` on the port): ``` SW9300# interface GigabitEthernet1/0/5 SW9300(config-if)# authentication restart ``` A healthy PEAP exchange in `debug dot1x events`: ``` *Mar 19 09:22:01.001: dot1x-ev: Received EAPOL Start on Gi1/0/5 *Mar 19 09:22:01.002: dot1x-ev: Sending EAP Request Identity to a4b1.c2d3.e4f5 *Mar 19 09:22:01.150: dot1x-ev: Received EAP Response Identity from a4b1.c2d3.e4f5 *Mar 19 09:22:01.151: dot1x-ev: Sending RADIUS Access-Request for a4b1.c2d3.e4f5 *Mar 19 09:22:01.280: dot1x-ev: Received RADIUS Access-Challenge *Mar 19 09:22:01.281: dot1x-ev: Sending EAP Request (TLS Start) to a4b1.c2d3.e4f5 *Mar 19 09:22:01.450: dot1x-ev: Received EAP Response (TLS) from a4b1.c2d3.e4f5 ... [TLS handshake packets] ... *Mar 19 09:22:02.910: dot1x-ev: Received RADIUS Access-Accept *Mar 19 09:22:02.911: dot1x-ev: 802.1X Authentication success for a4b1.c2d3.e4f5 ``` A PEAP failure where the TLS handshake completes but MSCHAP fails: ``` *Mar 19 09:22:01.001: dot1x-ev: Received EAPOL Start on Gi1/0/5 *Mar 19 09:22:01.002: dot1x-ev: Sending EAP Request Identity to a4b1.c2d3.e4f5 *Mar 19 09:22:01.150: dot1x-ev: Received EAP Response Identity from a4b1.c2d3.e4f5 *Mar 19 09:22:01.151: dot1x-ev: Sending RADIUS Access-Request for a4b1.c2d3.e4f5 *Mar 19 09:22:01.280: dot1x-ev: Received RADIUS Access-Challenge ... [TLS handshake completes] ... *Mar 19 09:22:02.850: dot1x-ev: Received RADIUS Access-Reject *Mar 19 09:22:02.851: dot1x-ev: 802.1X Authentication failed for a4b1.c2d3.e4f5 *Mar 19 09:22:02.852: dot1x-ev: Setting hold-off timer 60s for Gi1/0/5 ``` The Access-Reject after a completed TLS handshake points to credential validation failure (wrong username/password, AD account issue) or ISE authorization policy rejection. At this point, ISE's Live Logs have the specific failure reason. A failure where the TLS handshake itself does not complete: ``` *Mar 19 09:22:01.280: dot1x-ev: Received RADIUS Access-Challenge *Mar 19 09:22:01.281: dot1x-ev: Sending EAP Request (TLS Start) to a4b1.c2d3.e4f5 *Mar 19 09:22:31.281: dot1x-ev: SuppTimeout expired for a4b1.c2d3.e4f5 *Mar 19 09:22:31.282: dot1x-ev: Authentication failed - Supplicant timeout ``` Supplicant timeout during TLS handshake means the endpoint received the TLS Start but did not respond. Causes: supplicant not configured for this EAP method, Windows prompting the user for certificate trust but UI is suppressed, or the ISE certificate is not trusted by the endpoint's certificate store. Disable debug after collection: ``` SW9300# undebug all ``` ## Layer 6: ISE Policy and Authorization If ISE is accepting the authentication (Access-Accept) but the endpoint behavior is still wrong - landing in the wrong VLAN, no dACL applied, or being placed in the Auth-Fail VLAN - the issue is in ISE's authorization policy, not authentication. **Navigation: Operations > RADIUS > Live Logs > \[Click on entry\] > Authentication Detail** Scroll to the **Authorization Policy** section of the detail report. It shows: - Which Policy Set matched - Which Authorization Rules were evaluated - Which Authorization Profile was returned - The specific RADIUS attributes sent in the Access-Accept If the endpoint is landing in the wrong VLAN, compare the VLAN in the detail report against what you expect. If ISE is sending VLAN 40 (Auth-Fail) when you expect VLAN 10, the authorization rule matching is returning the wrong profile. **Navigation: Policy > Policy Sets > \[Policy Set\] > Authorization Policy** Review rule order. ISE evaluates authorization rules top to bottom and stops at the first match. If a catch-all rule is above a more specific rule, the catch-all always wins. Check: 1. Rule conditions - is the AD group condition correct? 2. Rule order - is the correct rule above the catch-all default? 3. Authorization Profile - does the profile have the correct VLAN assignment and dACL? For VLAN assignment details and specific authorization profile troubleshooting, see **Article 23 - Dynamic VLAN Assignment Not Working in 802.1X: Troubleshooting Guide**. ## Troubleshooting ### Symptom: Authentication fails intermittently - some endpoints authenticate, others do not, with no pattern **Cause:** RADIUS shared secret mismatch between the switch configuration and the ISE Network Device entry. When the shared secret is wrong, RADIUS packet authentication (the Message-Authenticator attribute) fails and ISE silently drops the packet or returns a generic error. Intermittency occurs when some packets happen to not include Message-Authenticator (e.g., test packets), while production 802.1X packets always include it. **Fix:** Verify the shared secret on both ends. On the switch: ``` SW9300# show running-config | section radius server ISE-PRIMARY radius server ISE-PRIMARY address ipv4 10.0.0.10 auth-port 1812 acct-port 1813 key ISEsecret123 ``` On ISE: **Administration > Network Resources > Network Devices > \[Device\] > Authentication Settings > Shared Secret**. Retype the shared secret on both ends - even one character mismatch causes complete authentication failure. After changing the key on the switch, the key is stored encrypted in running config; use `more system:running-config` to verify if needed. ### Symptom: Authentication succeeds (dot1x shows Authorized) but the endpoint has no network access **Cause:** Authorization succeeded but the dACL being applied is denying traffic, or the VLAN assignment placed the endpoint on an isolated segment. The port shows Authorized from the 802.1X perspective, but IP connectivity is blocked by policy. **Fix:** Check the applied policy: ``` SW9300# show authentication sessions interface GigabitEthernet1/0/5 details ``` Look at the `ACS ACL` line (dACL name) and `Vlan Group`. Then check what that dACL contains: ``` SW9300# show ip access-lists xACSACLx-IP-RestrictedAccess-12345678 ``` If the dACL has `deny ip any any` as the first matching rule or is missing `permit` statements for required traffic, the endpoint is connected but blocked. Correct the dACL in ISE: **Navigation: Policy > Policy Elements > Results > Authorization > Downloadable ACLs > \[dACL Name\]** Also verify the dACL is being downloaded correctly - see **Article 24 - dACL Not Applying Correctly in 802.1X**. ### Symptom: Only the first endpoint to connect on a multi-auth port succeeds; subsequent endpoints fail with no error in ISE logs **Cause:** The port is configured for `single-host` mode instead of `multi-auth`. In single-host mode, the switch only allows one authenticated MAC address on the port. Subsequent endpoints are blocked at the switch level and their EAPOL frames are never forwarded to ISE. **Fix:** Verify and correct the host mode: ``` SW9300# show authentication sessions interface GigabitEthernet1/0/5 ``` Check the current host mode: ``` SW9300# show running-config interface GigabitEthernet1/0/5 | include host-mode authentication host-mode single-host ``` Change to the appropriate mode. For a port with multiple data endpoints: ``` SW9300(config)# interface GigabitEthernet1/0/5 SW9300(config-if)# authentication host-mode multi-auth ``` For a port with a PC and an IP phone, use `multi-domain`. For host mode details, see **Article 13 - 802.1X Authentication Host Modes: Single-Host, Multi-Host, Multi-Domain, Multi-Auth**. ## Quick Reference: Failure Signature Matrix Port stays in Unauthorized, no username Where to Look Supplicant (client side) Key Command `show dot1x interface Gi1/0/5 details` Access-Reject from RADIUS Where to Look ISE Live Logs - failure reason Key Command `debug radius authentication` TLS handshake timeout Where to Look Certificate trust / supplicant config Key Command`debug dot1x events` Auth succeeds, wrong VLAN Where to Look ISE authorization policy Key Command `show authentication sessions Gi1/0/5 details` Auth succeeds, no IP access Where to LookdACL content Key Command `show ip access-lists xACSACLx-*` ISE not receiving requests Where to LookRADIUS reachability Key Command `show aaa servers` \+ `test aaa group` Intermittent failures Where to LookShared secret mismatch Key Command Retype key on both switch and ISE **What's Next:** **Article 21 - Client Stuck in Unauthorized State: Diagnosing 802.1X Port Issues** \- goes deeper into the specific scenario where the port stays Unauthorized, covering EAPOL capture analysis, supplicant diagnostics, and the switch-side state machine in detail.