A municipal architecture diagram lists 802.1X roles as supplicant, authenticator, and authentication server. How do those map on a typical staff WLAN?
Select an answer to reveal the explanation.
Short Explanation
Laptop asks, AP referees, RADIUS decides. That three-way handshake of roles is 802.1X in plain clothes. Mix them up and the diagram stops making sense.
Full Explanation
On a typical staff WLAN, 802.1X roles map as follows: the client device is the supplicant, the access point or wireless controller is the authenticator that mediates port access, and a RADIUS or AAA platform is the authentication server that evaluates EAP methods and returns accept or reject decisions. That mapping is foundational for municipal Enterprise designs and for understanding where misconfigurations create risk. The RADIUS server is not the supplicant, and the laptop is not the authenticator. The AP is not the authentication server that stores all user passwords locally only in a modern centralized design. Enabling WPA3 does not remove the authenticator role from the architecture. Exam caveat: controllers may centralize authenticator functions, but the conceptual trio remains client, authenticator, and AAA. Operational check: when reviewing a civic architecture diagram, label each box with supplicant, authenticator, or authentication server and verify trust relationships such as RADIUS shared secrets and client certificate validation settings. For municipal and campus engagements, keep the finding language tied to authorized scope, name the building or SSID class affected, and state the residual risk to residents or staff if the rejected option had been chosen. Re-validate after the next change window that the selected control still matches inventory, monitoring, and RoE abort criteria used by the city wireless program.