A boutique hotel runs a single guest SSID on its wireless controllers. Guests must reach an ISE-hosted splash page that validates a voucher code against the ISE guest database before any 802.1X credentials are exchanged, and the controller must hold the client in a webauth state until that check finishes. Which web authentication behavior supports this guest login flow?

The correct behavior is a captive-portal web authentication flow: the controller redirects the guest’s browser to the ISE-hosted portal, keeps the client in the webauth state, and waits for ISE to validate the voucher against its guest database. This preserves the required order: voucher validation occurs before any 802.1X credentials are exchanged, and the client is not released from webauth while the check is pending. Completing 802.1X before redirecting is a recognizable 802.1X-first design, but it fails the specified credential order even if ISE later validates the voucher and webauth remains in place during that check. Using an external guest database is also a common portal integration pattern, but it does not meet the explicit requirement that the voucher be checked against ISE’s guest database. Moving the client into a restricted pre-auth role can be used to provide limited connectivity during a portal process; here, however, it releases the client from webauth before validation finishes, contrary to the controller-state requirement. Exam caveat: a restricted role or ACL is not necessarily equivalent to a controller’s webauth state, even if both limit access. Practical check: inspect the controller’s client session state and authentication logs alongside ISE’s guest-validation records to confirm the redirect, database lookup, and state transition occur in the required order.