A municipal hospital campus sees a new laptop fail wired 802.1X before any authorization ACL is applied. Where should engineers first confirm the EAP exchange is progressing?
Select an answer to reveal the explanation.
Short Explanation
If the laptop never finishes shaking hands, check the door and the badge office—not the parking garage. EAPOL lives on the access switch; RADIUS carries the conversation to ISE. Confirm those hops before chasing DHCP or firewall rabbit holes.
Full Explanation
When a municipal hospital laptop fails wired 802.1X before any authorization ACL appears, the EAP exchange itself has not completed successfully. Troubleshooting must start at the authenticator and the RADIUS path: confirm EAPOL locally on the access switch and verify Access-Request/Accept (or Reject) toward ISE. Until those hops succeed, authorization results never apply, so staring at downstream ACL counters wastes time.
Looking only at core firewall logs is wrong because EAP terminates at the closet authenticator, not at the firewall. Inspecting only laptop BIOS is incorrect because 802.1X depends on OS/supplicant, switch, and RADIUS state—not BIOS settings alone. Checking only the DHCP server assumes address assignment always precedes EAP identity; in reality EAP can and should progress before or independently of DHCP success, and DHCP will not explain a failed EAP handshake.
Exam caveat: authorization ACLs and dACLs matter only after Access-Accept; do not confuse pre-auth open/low-impact modes with a completed EAP failure. Operational check: on the failing port, show authentication session and EAPOL counters, correlate ISE live logs for the MAC/username, and capture whether the reject is credential, certificate, or policy related before changing hospital-wide templates.