Security

Seem to be having Session-Timeout issues on CPPM 6.8.2.... more specifically whats displayed in Access Tracker.

I tend to send back an access accept packet for real breathing users with a Session Timeout of 3600 secs and its been like that for a long time.. Works just fine in 6.8.0 and I think in 6.8.1 ( TBH never checked).  However, I recently upgraded our Building ( i.e. my dev server) to 6.8.2 and now I'm seeing Session-Timeout values in access tracker that are NOT 3600, even though the configs say thats what I set up.

As an example, my EAP-TLS session for my iPhone is set to 7200 seconds ... indicated by the Enforcement profile shown in the attached image. My phone hasn't reauth'd so am thinking it might be an Access-Tracker isssue rather than actually auth'ing every 120 seconds

Anyone else seen this ?

A

Are you saying ClearPass is sending incorrect session timeout? 

If so please share sshots of your Enforcement Profile. For faster resolution work with TAC.

I'm saying clearpas is *showing* a Session timeout value in the Access Tracker output tab that doesn't match up with what is defined in the enforcement profile.

Also, in terms of reauths, things seem to be o.k

Sorry but i think there is a config issue here if you are saying that the Enforcment Profile sent = X and X has a session timeout of Y seconds but you are seeing the value being sent as Z. It is highly unlikely. 

Please work with TAC or share screenshots of your policies and profiles for troubleshooting.

Our eduroam service (for my EAP-TLS iPhone) uses the following Enforcement profiles

UoY Wireless Allow Access Profile - 130318

UoY Session Timeout - 7200

[Update Endpoint Known]

Which gives the following in the Access-Tracker output

RADIUS Response

Note that the Session-Timeout  swtting is 180 and not 7200 as defined in the profile. On our production 6.8.0 setup with the same config, the Value displayed  for Session-Timeout is a correct 7200

Rgds

Alex

However, Some services do display the correct session-timeout ... :-(

Have never come across something like this. It is not possible to troubleshoot this here. Please work with TAC.

Ensure the Enforcement Profile being sent within the service has a static value and no getting an expiration time using SQL based source.

Having just upgrqadedf our production cppm system to 6.8.2 from 6.8.0 everything is working on that one just fine. Methinks I'll try the old switch it off and on approach for our building/dev cppm cluster :-)