At a distribution warehouse, 300 handheld scanners join an SSID that authenticates against ISE with PEAP, and every attempt ends in an Access-Accept. When an engineer edits the authorization rule mid-shift, the connected scanners keep their original access until they roam or reconnect. Which controller-to-ISE setting must be verified first to push a new authorization result to a live session?
Select an answer to reveal the explanation.
Short Explanation
Your scanners are already authenticating, so the gap is after the Access-Accept: the update is not reaching the live session. Matching the dynamic authorization settings lets ISE send a change to the controller mid-session. Think of it as making sure you send the change notice to the right address.
Full Explanation
Authentication already succeeds, so the missing piece is dynamic authorization: ISE must send a Change of Authorization (CoA) to the controller to update a session that is still open. The message can reach the controller only if ISE has the controller’s RADIUS source IP configured and both ends use the same CoA port. Raising the WLAN reauthentication timer can prompt scanners to obtain a fresh result later, but it defers the change until reauthentication rather than applying it live. The allowed protocols list governs the initial PEAP negotiation, which the successful Access-Accept shows has already completed; it does not deliver a new authorization result to an active session. The shared secret authenticates RADIUS and CoA packets, but successful Access-Accepts indicate the RADIUS secret used for those requests matches; the setting to verify first for this live update is the CoA destination and port. Exam caveat: on Cisco wireless controllers, a live change that carries a new VLAN or ACL also depends on AAA override being enabled for the WLAN. Practical check: push a restrictive dACL from an edited rule, then watch ISE’s RADIUS live logs for the CoA request.