clients frequently re-authenticate with ISE

[cghaderpour]

Hello friends

I have Cisco ISE and Meraki in place to authenticate wireless clients (windows and Apple iPads) using eap-tls and certificate. 

The authentication process seems to be working and I see clients auto join the new SSID when they get the new wifi profile and machine certificate. However in live logs I see many clients re-authenticate frequently on ISE and keep doing that for the whole day and some authenticate once and stay connected. I'm wondering what could cause this happening for them. could AP roaming cause this issue? I mean when client move ap to ap do they need to re-authenticate with ISE again? If this is not the case what else can be the root cause?

Thanks 

[MHM Cisco World]

Share live log detail of ISE 

MHM

[Flavio Miranda]

@cghaderpour 

 "could AP roaming cause this issue?"

Nop.

"I mean when client move ap to ap do they need to re-authenticate with ISE again?"

They shouldn´t. If they are disconnecting on roam, something is wrong with Meraki configuration. 

"If this is not the case what else can be the root cause?"

You need to first identify if roaming is causing this. If so, you need to check the confiuguration on the Meraki. 

Other possibilities would be RF problem, clients is actually disconnecting from the AP and not actually roaming. And you can also check for session timeout. Maybe your session time out is too small and clients are re-auhenticating too often.

[Arne Bier]

In my experience this is exactly what happens in 'standard wireless networks' (no optmizations in place), since the keying material is not cached or distributed amongst the APs - therefore each time a client associates to a new AP, the keying material must be generated from scratch (full 802.1X authentication).

There are wireless standards that can assist with this (CCKM etc. - this one only helps to optimize the case where a client roams BACK to an AP where the keying material has been created previously - it does not help in cases of roaming to a new AP)

I believe that 802.11r (Fast Roaming) will share this keying material across other APs in the same L2 domain. @cghaderpour check your SSID and enable 802.11r (Fast Roaming) and also ensure that you are running an up to date AP firmware.  Clients must support 802.11r to benefit from this.

[cghaderpour]

Hello Arne,

Thanks for explaining this and recommendation.

I checked on 802.11r to see if I can make that work but due to COA being enabled on my SSID for change of authentication I won't be able to have 802.11r active at the same time.

I disabled client balancing and enabled Band steering in RF profile. this actually helped reducing the number of authentication significantly.

I wish there was a way to have this fully resolved and keep the clients connect during the roaming without re-authentication.  

[Karsten Iwen]

CoA is supported with .11r for quite some time. Is there any specific reason that you run outdated firmware? I can only think of legacy APs like MR32 or older.

But do you have any workflow configured that needs CoA, like Posturing or changed AuthZ after Profiling? Against common belief, you don't need CoA to send a VLAN or a Group-Policy.

[Jagermeister]

Is it?

In my Meraki environment we are running up to date firmware but 802.1R and CoA cannot be enabled at the same time. 

[Karsten Iwen]

Oh, damn, thinking again of it, I mixed up my mind with Catalyst ... 

You are right, Meraki disables FastRoaming to make sure the RADIUS server can also send up to date AuthZ with every roam and always knows which AP should receive the CoA. IMO, a not optimal design decision, as the initial AP could always forward it. But for real life, most of the time 802.11r is what is typically needed.

[Jagermeister]

Yes, I agree. In my environment I'm now facing the challenge: Do you want CoA or 802.1R, which kind off forces me to create a separate SSID for voice clients that roam a lot. So, the Catalyst series AP's actually do support both? Interesting, after speaking to Meraki support and reading about this, I thought that both CoA and 802.1R could not work together. 

[Karsten Iwen]

In Catalyst environments, it is easy as the same device (the controller) typically controls both FT and CoA.

[Arne Bier]

To he honest I don’t know this was even an issue. But according to the Meraki forums, the reason that roaming enhancements such as 802.11r and CoA, are mutually exclusive is because the CoA must be sent to the AP on which the endpoint roamed to. And somehow due to 802.11r and other protocols, this is no longer possible. I have never come across this on Cisco wireless. Meraki does have some weird product limitations that we take for granted in Cisco product. I remember how long it too Meraki to implement proper RADIUS Accounting support

[Karsten Iwen]

Perhaps I was indeed thinking about the right platform, but I don't remember exactly. Even with CoA enabled on my Meraki SSID, 802.11r (small "r") keeps activated. I'll do some testing later to find out if the documentation and warnings are wrong or if CoA is just not working when 802.11r is enabled.

[Karsten Iwen]

I did some tests with both 802.11r *and* CoA enabled. Conclusion: It doesn't work, but it is entirely different from what the documentation and the Dashboard state.

If both are enabled, 802.11r will still be used and will work as expected. However, CoA only works when the client is connected to the AP, where the initial connection was made. When the client is connected to a different AP, the AP answers with CoA-NAK, "Session-Context-Not-Found".

EDIT: I found out that this behavior is only valid for existing networks, that had specific settings before. For new networks, the behavior should align with the documentation (I didn't test that).

[MHM Cisco World]

I send you PM 

MHM

[Arne Bier]

What for and why?  It's more helpful to share your advice in a public forum, because it helps others. I'd be keen to know what advice you want to offer.