ISE 1.4 API remove stale sessions

[anvolkov]

Hello team,

My Customer has a question how we can delete only stale sessions from ISE (that were not removed correctly after acct-stop, for example, etc).

In the API guide I can see we can delete either sessions for individual MAC addresses or all of them (http://www.cisco.com/c/en/us/td/docs/security/ise/1-4/api_ref_guide/api_ref_book/ise_api_ref_ch2.html#pgfId-1072950). I really have doubts if ISE can do it, but just to double check – is it possible to distinguish sessions that are really active and “wrong” stale sessions?

[howon]

Anastasiya, I assume by stale sessions you are talking about sessions that are no longer active on NAD, but ISE still reports that the device is still connected. Yes, the API can be used to remove them as document states, but ISE will also remove them periodically on its own. For any authentication request without RADIUS accounting message, ISE will remove them in 2 hours. If RADIUS accounting start was received for a session, but there were no interim accounting received, then ISE will remove the session after 5 days of no RADIUS accounting activity.

Hosuk

[anvolkov]

Hosuk,

Thank you for your response. Yes, I know those sessions should be removed after some time. Our current issue is that it does not happen. And while we are troubleshooting it, the Customer wants to clear them manually.

The question is - how to remove only stale sessions, not all of them? As far as I understand, "curl -X DELETE https://<mntnode>/admin/API/mnt/Session/Delete/All" will delete ALL the sessions, including normal active ones, am I right?

[Craig Hyps · Accepted solution]

The short answer is no.  The API is able to clear sessions that would be visible from Live Sessions log.  The list of active sessions is based on the information communicated by access device.  It is for this reason that RADIUS Accounting is critical in maintaining accurate session info.  If no RADIUS Accounting Stop received, then there is no way to determine if user session still exists on the switch. Consequently, there is no way to use API to clear only sessions where client already disconnected.  This is why we have the session maintenance logic that Hosuk describes.  In event of RADIUS Accounting is not configured or packet does not reach ISE, we will eventually clear the session.

Note that the logic also applies to sessions that may still be active on the access device.  If ISE sees no auth, profiling, or posture activity from a given endpoint, and RADIUS accounting updates are not sent, ISE will eventually clear the session from ISE even though endpoint may still be connected to network.  Again, proper configuration of RADIUS Accounting will avoid such conditions.  Make sure customer has this enabled along with proper update intervals set to maintain session.

/Craig

[Jeffrey Jones]

What about session that are terminated, this affects ability to push windows updates to an endpoint if we get get to it on the network.

[Craig Hyps]

Terminated session implies "cleared at NAD".  ISE will rely on RADIUS accounting to clear in ISE if terminated at NAD.

Cleared session due to ISE maintenance in ISE will remove session from session directory but not impact session if still actively connected to network.

If need to push updates to client, be sure to do so before you decide to terminate them!  In general, admin would not terminate sessions.  That is a function of client disconnect, session / idle timers, ANC policy, purge event, etc.

[Jeffrey Jones]

user logs off device, goes to a terminate session state, can no longer get to endpoint.

[Craig Hyps]

If user logs off and security policy is that unauthenticated endpoints should not get network access, then system is working as intended.  This is a very common policy. 

However, if you wish to allow unauthenticated endpoints access to network, or other systems to access it, then recommend you look into Low Impact Mode which allows the application of a PRE-AUTH ACL policy to allow certain functions like PXEBOOT and imaging software to operate and access endpoint in absence of explicit host or user authentication.

An alternative is to fallback to MAB whereby authentication policy is to CONTINUE to authorization -- even if MAC lookup fails -- to authorize port with Access-Accept and some permissions to allow basic services like DHCP, DNS, access to web auth portals, or even access to patch and imaging servers.

Craig