Guest access for the public library must not accept staff Active Directory passwords on the captive portal. What should the designer do?
Select an answer to reveal the explanation.
Short Explanation
The guest portal must never become a phishing booth for employee AD passwords. Give guests their own workflow or IdP. Wiring the portal to the same staff LDAP—or replaying PEAP—is exactly the anti-pattern.
Full Explanation
Guest access for the public library must not accept staff Active Directory passwords on the captive portal; implement a separate IdP or guest workflow so staff directory passwords are never solicited or accepted there. Binding the guest portal directly to the same AD LDAP bind used for PEAP creates a high-value phishing target on an untrusted SSID. Training guests to use employee usernames with a shared suffix normalizes staff credential use on guest paths. Caching successful staff PEAP credentials and replaying them for guest MAC addresses is a severe identity bypass. Exam caveat: guest portals must be identity-isolated from staff AAA—even if both ultimately provide Internet access. Operational check: configure guest sponsorship or one-time vouchers against a non-staff IdP, penetration-test that staff AD passwords are rejected, and monitor portal logs for staff username patterns. Publish the rule in the library acceptable-use and municipal guest design standard. 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.