An office WLAN must send every unauthenticated browser request to the ISE login page using the controller's own redirect setting, before any RADIUS request is sent. ISE then validates the submitted credentials against its own internal user store, and the controller finishes the RADIUS exchange for the session. Which web authentication mode matches this redirect and credential-handling flow?
Select an answer to reveal the explanation.
Short Explanation
You're after the mode where the network device starts the redirect itself, like a doorman pointing you to the desk before any paperwork, and ISE then checks what the user submitted. That's local web auth in a nutshell. Central web auth would tuck that redirect into ISE's Access-Accept reply instead.
Full Explanation
Local web authentication puts the redirect in the hands of the network access device: the controller matches the browser request against its own redirect configuration and forwards it to the ISE-hosted login page before any RADIUS packet is exchanged. The user then submits credentials to that page, ISE validates them directly against the configured identity store, and the controller completes the RADIUS authentication for the session. Central web auth misses the required ordering, because there the NAD must first send an Access-Request and ISE answers with the redirect URL as its authorization. The controller's built-in login page misses the identity requirement, because credentials are checked in the controller database and never reach ISE. The hotspot flow misses that same requirement, since a shared venue code proves attendance rather than identity. Exam caveat: release notes and vendor slides sometimes blur these two web auth names, so reason about who issues the redirect instead of trusting the label. Practical check: capture traffic on the controller and confirm the HTTP redirect to the portal appears before the first RADIUS packet.