A hospital runs central web authentication on its guest WLAN. Users reach the splash page and accept the usage terms, and ISE logs an Access-Accept carrying the guest profile, yet the clients stay in the pre-auth role with no internet access. Which step must ISE perform so the controller applies that guest profile to the live session?
Select an answer to reveal the explanation.
Short Explanation
After you submit the portal form, ISE must send the controller a CoA reauthentication request so it can apply your guest profile to the live session. An Access-Accept is like a ticket that doesn’t update a trip already in progress, and neither AAA override nor changing the endpoint record refreshes that session.
Full Explanation
Central web authentication runs in two phases. First, the network device intercepts HTTP and points the client at the ISE portal using a pre-authentication ACL plus a redirect URL. After the user submits the form, ISE's decision becomes enforceable when the device reauthorizes the session. ISE sends a RADIUS Change of Authorization (CoA) request to trigger that reauthorization; the controller then sends a fresh Access-Request, and the resulting Access-Accept can carry the dACL, VLAN, or role for the client. AAA override does not trigger reauthorization; it allows returned attributes to override configured values when the device processes authorization. Expecting the original Access-Accept to refresh the live session fails because the controller will not re-evaluate policy until something triggers a new request. Writing the profile into the ISE endpoint record does not update the session on the network device enforcing it. CoA can trigger reauthentication or a session bounce depending on the device, so focus on the reauthorization trigger rather than one exact packet sequence. Practical check: watch the RADIUS live log for the CoA and confirm the controller reports a new authorization result.