Public kiosk tablets at the clerk’s office will use a guest-style SSID. Why must that SSID avoid the staff RADIUS realm?
Select an answer to reveal the explanation.
Short Explanation
Don’t let lobby kiosks check in at the employee RADIUS desk. Separate guest/kiosk auth so staff passwords and policies don’t leak into public devices—and never ‘fixnet the enable secret’ as Wi-Fi auth.
Full Explanation
Public kiosk tablets at the clerk’s office on a guest-style SSID must avoid the staff RADIUS realm so guest and kiosk authentication stay isolated from staff Enterprise AAA, preventing credential and policy crossover. Kiosks should not inherit employee group policies via the staff realm. One AAA identity space for guests and staff is poor segmentation of identity. Authenticating kiosks with the wireless controller’s enable password via Telnet is an administration anti-pattern unrelated to client auth design. Exam caveat: realm and IdP separation for guests/kiosks is as important as VLAN separation—SSID name alone is insufficient if AAA is shared unsafely. Operational check: point the kiosk SSID at a guest IdP or local guest AAA, deny staff AD binds on that portal, and firewall kiosks to public services only. Record realm separation in the clerk’s-office wireless build sheet for municipal auditors. In municipal WLAN operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the infrastructure versions and client fleets used by the civic environment.