A regional clinic runs guest Wi-Fi with central web authentication: the controller redirects the guest's browser to the ISE hotspot portal, the guest accepts the terms, and the login succeeds. Several tablets then keep the pre-authentication policy and never pick up the guest role on the WLAN. Which step of the central web authentication flow should be verified first to apply the post-login result?
Select an answer to reveal the explanation.
Short Explanation
Your successful login shows that the redirect and portal are working, so you can focus on the post-sign-in push. Verify that ISE sends a change of authorization to the controller, prompting it to obtain a fresh result and apply the guest role. It’s like checking in at the desk but never getting handed your room key.
Full Explanation
Central web authentication has two phases: the controller redirects the browser to the ISE portal for login, then ISE notifies the network access device that the client’s state has changed. Verify that ISE sends a RADIUS change of authorization (CoA) after the terms are accepted; this prompts the controller to obtain a fresh authorization result and apply the guest role, downloadable ACL, and guest VLAN. Without the CoA, the controller can keep enforcing the pre-authentication policy installed before the redirect. Checking the redirect ACL for DNS and HTTPS misses the issue: the guest already reached the portal and completed login, so the redirect path is working. Checking whether the portal certificate is trusted before login is also misplaced, because an untrusted certificate would block the sign-in page rather than allow the guest to accept the terms. Verifying the shared RADIUS secret addresses the first access request, which has already succeeded. Exam caveat: some designs also depend on a reauthentication timer, so treat CoA as the trigger rather than the entire policy change. Practical check: watch the ISE live log as a test client logs in and confirm that a CoA follows the portal submission.