Wireless Posture with Session&idle timeout

[bakaholic39]

HI all!

I have an issue (though I am not sure if it should be considered an issue) regarding wireless clients with Posture (CSC). After a client associates with the AP, it completes the Posture assessment and receives a Compliant status. When the client reaches the idle timeout threshold (assumed to be 300s), it normally reconnects to the AP immediately via Auto Connect.

The problem starts here, on the ISE live logs, the client appears to start a new RADIUS session and the Posture state shows as Pending. However, on the Posture agent (CSC), the status remains Compliant and no new Posture assessment is initiated. As a result, although a new RADIUS session is created, the client never receives a CoA message and remains stuck in the Pending state on the ISE live logs.

I am not sure if anyone has encountered this situation before. How can we address it?

From a quick search, configuring a Posture lease may help mitigate the issue, but is it possible to trigger the CSC to initiate a new Posture assessment without clicking Scan Again when this scenario occurs?

. 9800 17.15.5 with ISE 3.4 p5

[olasupoo · Accepted solution]

Hi Bakaholic39,

That Pending is expected, ISE puts every new RADIUS session into Pending unless a posture lease is set. The reason idle timeout triggers it but a session timeout usually doesn't is the session ID: an idle timeout deauthenticates the client, so the reconnect is a brand new association with a new Audit-Session-Id, which ISE resets to Pending. A session-timeout reauth can keep the same ID if your authz profile uses RADIUS-Request (Maintain Connectivity During Reauthentication), so posture survives. That explains the difference but isn't your fix, since RADIUS-Request does nothing for an idle deauth. And on a quick reconnect to the same SSID, the Secure Client module often doesn't see a network change, so it never re-probes and just sits on its cached Compliant.

First thing to rule out: check your posture-unknown authz actually pushes the redirect or a limited DACL. If it hands out access without nudging the agent, nothing prompts CSC to re-probe and a lease would just mask that.

The lease is the right fix for the churn, but pair it with PRA. While the lease is active ISE trusts the stored result and doesn't re-check the endpoint, so PRA re-validates the live session to catch anything that drifts out of compliance. Keep the lease short, 4 to 8 hours rather than days. Raising the 300s idle timeout (your value is the 9800 default, worth confirming) also cuts how often you hit this.